Skip to content

Fix unique ID generation #775

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

SlavaSkvortsov
Copy link

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
Copy link
Member

elprans commented Jun 22, 2021

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants