Auto-reconnect on BrokenPipe outside transactions
#510
Conversation
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
…er since last use
…ng transaction command Automatically reconnecting for an in-transaction queries is not supported, as we’d have to replay all previous queries and still risk inconsistency if any subsequently issued application queries depended on data previously read during the disconnected transaction. We’d *also* have to keep a log of all previously returned data to verify that it hasn’t changed when reissuing the command – an unacceptable overhead, particularly since applications must be able to handle transaction conflicts anyway and this patch just makes disconnects look like any other “please retry transaction” condition.
Committing partial transactions is a great way to induce data corruption by committing inconsistent data to the database. Transaction MUST always form a unit! Fortunately, this probably never mattered in practice as PostgreSQL will put transactions with failed commands into an *aborted* state, where the only valid subsequent in-transaction command is rolling back partially or completely: > […] Moreover, ROLLBACK TO is the only way to regain control of a transaction block that was put in aborted state by the system due to an error, short of rolling it back completely and starting again. https://www.postgresql.org/docs/current/tutorial-transactions.html So this “only” improves error messages and avoids an unnecessary round trip, not change application observable behaviour.
Author
|
This can be manually tested:
This applies to bewCloud, for instance. |
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.
Reconnects to PostgreSQL when receiving
BrokenPipeupon executing freestandig query or transaction start.In-transaction queries are not retried, since we’d have to replay all previous queries and still risk inconsistency if a subsequently issued queries depended on data previously read during the aborted transaction. (We’d also have to keep a log of all previously returned data to verify that it hasn’t changed when reissuing the command!)
This patchset does convert
BrokenPipetoTransactionErrorto let applications know that they should restart the transaction: If the database is really down, the subsequent.begin()will then fail with aConnectionError.This allow removes the calls to
.commit()in the transaction error handling, see last commit message for why and why this doesn’t actually change application observable behaviour.Fixes #436