Repository navigation
fix(pg): send Sync after error in paged queries - #3831
Open
princejain756 wants to merge 1 commit into
Open
princejain756 wants to merge 1 commit into
princejain756 wants to merge 1 commit into
Conversation
A query using the rows option drives the portal with Flush instead of Sync. When the server answers ErrorResponse it enters ignore-till-sync mode, so ReadyForQuery never arrives and the connection stays wedged: the failed query rejects but every queued query waits forever. Sending Sync when an ErrorResponse hits a rows-limited query lets the backend leave error recovery and emit ReadyForQuery again. Fixes brianc#3707.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Fixes #3707
A query configured with
rows(portal suspension) is driven byFlushrather thanSync:_getRowssendsExecute(rows: N)plusconnection.flush()on the initial dispatch and again after everyPortalSuspended, andSynconly goes out fromhandleCommandComplete/handleEmptyQuery.When the server answers
ErrorResponseinstead, it enters ignore-till-sync error recovery and withholdsReadyForQuery. The query itself rejects fine, but the client'sreadyForQueryflag stays false and every subsequent query queues forever.This sends
Syncfrom_handleErrorMessagewhen the active query is paged, so the backend exits error recovery and emitsReadyForQuery. The bind-error path inQuery.prepareis unaffected: it already syncs before callinghandleError, and that path never reaches_handleErrorMessage.Added
test/integration/gh-issues/3707-tests.jscovering the report: division by zero mid-portal, followed by aselect 1that previously hung.