When prepared statements are disabled, avoid relying on them harder #1065
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It appears that PgBouncer's
transaction
pooling mode does not considerimplicit transactions properly, and so in a [
Parse
,Flush
,Bind
,Execute
,Sync
] sequence,Flush
would be (incorrectly) considered byPgBouncer as a transaction boundary and it will happily send the
following
Bind
/Execute
messages to a different backend process.This makes it so that when
statement_cache_size
is set to0
, asyncpgassumes a pessimistic stance on prepared statement persistence and does
not rely on them even in implicit transactions. The above message
sequence thus becomes
Parse
,Flush
,Parse
(a second time),Bind
,Execute
,Sync
.This obviously has negative performance impact due to the extraneous
Parse
.Fixes: #1058
Fixes: #1041