[SlavaSkvortsov]

If asyncpg is used in different processes/threads it will generate prepared statements with the same ID. It causes conflicts and errors (like this one, for example). One of the options is using PID in the _get_unique_id function, but I think it will be overkill.

[elprans]

If asyncpg is used in different processes/threads it will generate prepared statements with the same ID

Prepared statements are not global, they are created per connection, so there is no danger of conflict between processes there. As for multiple threads, the counter increment in Python is thread-safe, so I fail to see how a conflict could arise even if you share a connection between threads (which is not recommended at all as nether asyncpg nor asyncio in general are thread-safe). Do you have a sample of code that reproduces the problem? The linked SQLAlchemy issue is about pgbouncer, which is known to not work with prepared statements properly.

[SlavaSkvortsov]

Prepared statements are not global, they are created per connection

Wow, it's new information for me. The funny thing, we had the issue (we have no PgBouncer) and modifying the connection class in the way I suggested in the PR solved it.

I have no example to reproduce the issue, so I'll close the PR, but I still think using UUID is better than a global var.