fix: send Sync on error during rows-limited (portal) queries#3712
Open
houzhonglogic wants to merge 1 commit into
Open
fix: send Sync on error during rows-limited (portal) queries#3712houzhonglogic wants to merge 1 commit into
houzhonglogic wants to merge 1 commit into
Conversation
handleError was missing the connection.sync() call that handleCommandComplete already has for the rows-limited path. When a query with the rows option hits an ErrorResponse from the server, handleError returns the error to the caller but never sends Sync. The server stays in an extended-query subtransaction waiting for Sync, ReadyForQuery never arrives, and the connection is permanently wedged — every subsequent query on that connection queues forever. handleCommandComplete has had this sync call since rows support was added. handleError simply forgot to do the same. Refs: 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
2 participants
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.
Problem
When a query with the
rowsoption (portal suspension mode) encounters anErrorResponsefrom the server,handleErrorreturns the error to the caller but never sendsSync. The server stays in an extended-query subtransaction waiting forSync,ReadyForQuerynever arrives, and the connection is permanently wedged — every subsequent query on that client queues forever.This was reported in #3707: "Error during a
rows-limited query permanently wedges the connection —handleErrorsends no Sync".Fix
handleCommandCompletealready has theconnection.sync()call for therowspath (line 93–94).handleErrorwas simply missing the same check. This PR adds it.Prior art
The
pg-cursorpackage handles this correctly in its own error path. The mainpgpackagesrowsfeature uses a different internal path and was overlooked.Testing
pg-cursoralready has error-handling tests that verify the connection recovers after a cursor error. The main packagesrowspath should have the same coverage — this fix brings it in line with cursor behaviour.