-
Notifications
You must be signed in to change notification settings - Fork 417
InterfaceError On Exception Inside PoolAcquireContext But Outside Transaction #232
New issue
Have a question about this project? No Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “No 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? No Sign in to your account
Labels
Comments
Interesting case. Here's what I think happens when
Basically, The second case, in contrast, has no The proper fix here would be to serialize transaction exit with pool release somehow. |
elprans
added a commit
that referenced
this issue
Dec 3, 2017
Similarly to other connection-dependent objects, transaction methods should not be called once the underlying connection has been released to the pool. Also, add a special handling for the case of asynchronous generator finalization, in which case it's OK for `Transaction.__aexit__()` to be called _after_ `Pool.release()`, since we cannot control when the finalization task would execute. Fixes: #232.
elprans
added a commit
that referenced
this issue
Dec 3, 2017
Similarly to other connection-dependent objects, transaction methods should not be called once the underlying connection has been released to the pool. Also, add a special handling for the case of asynchronous generator finalization, in which case it's OK for `Transaction.__aexit__()` to be called _after_ `Pool.release()`, since we cannot control when the finalization task would execute. Fixes: #232.
elprans
added a commit
that referenced
this issue
Dec 3, 2017
Similarly to other connection-dependent objects, transaction methods should not be called once the underlying connection has been released to the pool. Also, add a special handling for the case of asynchronous generator finalization, in which case it's OK for `Transaction.__aexit__()` to be called _after_ `Pool.release()`, since we cannot control when the finalization task would execute. Fixes: #232.
elprans
added a commit
that referenced
this issue
Dec 4, 2017
Similarly to other connection-dependent objects, transaction methods should not be called once the underlying connection has been released to the pool. Also, add a special handling for the case of asynchronous generator finalization, in which case it's OK for `Transaction.__aexit__()` to be called _after_ `Pool.release()`, since we cannot control when the finalization task would execute. Fixes: #232.
elprans
added a commit
that referenced
this issue
Dec 4, 2017
Similarly to other connection-dependent objects, transaction methods should not be called once the underlying connection has been released to the pool. Also, add a special handling for the case of asynchronous generator finalization, in which case it's OK for `Transaction.__aexit__()` to be called _after_ `Pool.release()`, since we cannot control when the finalization task would execute. Fixes: #232.
No Sign up for free
to join this conversation on GitHub.
Already have an account?
No Sign in to comment
the issue with a local PostgreSQL install?: Using local install.
uvloop?: Unsure.
Unexpected Behaviour Example
If an exception occurs outside of a transaction block but within a pool acquire block, an
InterfaceError
is raised.This will cause
asyncpg.exceptions._base.InterfaceError: cannot perform operation: another operation is in progress
which I did not expect.Expected Behaviour Example
If the transaction block is moved to encompass the exception, this behaves as expected.
This will cause
Exception
as I expected.The text was updated successfully, but these errors were encountered: