Repository navigation
Conversation
tokio-postgres returns from a cancel once the request is written. A read's statement_timeout could end the statement first, and the server then applied the late request to the next statement on that backend. Wait for the server to close the cancel connection, as libpq does.
This branch has not been deployed
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.
Why
After a PostgreSQL query timed out or was stopped, the next query on the same connection could fail with "canceling statement due to user request". tokio-postgres'
cancel_query_rawreturns before the server has read the cancel, so the cancel could land on the next statement. It showed up as an intermittentdeadline_1s_timeout_server_cancelledfailure in CI.Change
PQcanceldoes, before the stop counts as delivered; the server closes it only after signalling the backend.EngineStop::stopcontract says so.Verified
Two docker tests delay the cancel on a test route so the race happens every time; both failed on the old code with the CI error and pass now, along with the cancellation and conformance cases.
Not in this PR