Commits on Aug 21, 2026
-
Do not reset statement_timeout indicator outside of ProcessInterrupts
The only way that ProcessInterrupts can know why QueryCancelPending is set is by looking at the indicator bits of the various timeouts. The STATEMENT_TIMEOUT indicator was being reset in two places, causing ProcessInterrupts to report "user request" instead of "statement timeout". The primary reason for this patch is that this different error message caused a test to be flaky. The reason this was happening is because enable_statement_timeout would be called twice for a single query. The intent of calling enable_statement_timeout twice is that the second call was a no-op, but that was not the case in practice. If the timer expired right before the second call, then the timer would restart and unset the current indicator. The QueryCancelPending flag would still be true, so on the next CHECK_FOR_INTERRUPTS it would throw the "canceled statement due to user request" error. The disable_statement_timeout function has a similar theoretical race condition, where it would reset the indicator, but leave the cancel flag set. So that one was changed too, even though none of our tests actually trigger that specific bug. The downside of keeping these indicators set, is that they can leak outside of the query that's being run. To make sure that this causes no problems in practice, ProcessInterrupts now also checks that DoingCommandRead is false before canceling because of statement_timeout or lock_timeout, in addition to resetting of those indicators (which it already did). Given that CHECK_FOR_INTERRUPTS is called right before changing the DoingCommandRead back to false, this will reset the indicators before entering the next query. This leaking of timeout flags was actually already possible if a timeout fired before the disable_statement_timeout call, but after the last row sent. Which would result in a client receiving a CommandComplete, immediately followed by an ErrorResponse for that just completed command. Author: Jelte Fennema-Nio <postgres@jeltef.nl> Reported-By: Alexander Lakhin <exclusion@gmail.com> Reported-By: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>
authored and Commitfest Bot committed
Aug 21, 2026
