Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 61ace8f

Browse files
committed
Prevent idle in transaction session timeout from sometimes being ignored.
The previous coding in ProcessInterrupts() could lead to idle_in_transaction_session_timeout being ignored, when statement_timeout occurred earlier. The problem was that ProcessInterrupts() would return before processing the transaction timeout if QueryCancelPending was set while QueryCancelHoldoffCount != 0 - which is the case when reading new commands from the client. Ergo when the idle transaction timeout would hit. Fix that by removing the early return. Alternatively the transaction timeout code could have been moved up, but that early return seems like an issue that could hit other cases too. Author: Lukas Fittl Bug: #14821 Discussion: https://www.postgresql.org/message-id/20170921010956.17345.61461%40wrigleys.postgresql.org https://www.postgresql.org/message-id/CAP53PkxQnv3OWJpyNPGJYT62uY=n1=2CF_Lpc6gVOFnc0-gazw@mail.gmail.com Backpatch: 9.6-, where idle_in_transaction_session_timeout was introduced.
1 parent fbac00a commit 61ace8f

File tree

1 file changed

+15
-17
lines changed

1 file changed

+15
-17
lines changed

src/backend/tcop/postgres.c

Lines changed: 15 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -2914,26 +2914,24 @@ ProcessInterrupts(void)
29142914
" database and repeat your command.")));
29152915
}
29162916

2917-
if (QueryCancelPending)
2917+
/*
2918+
* Don't allow query cancel interrupts while reading input from the
2919+
* client, because we might lose sync in the FE/BE protocol. (Die
2920+
* interrupts are OK, because we won't read any further messages from
2921+
* the client in that case.)
2922+
*/
2923+
if (QueryCancelPending && QueryCancelHoldoffCount != 0)
29182924
{
2919-
bool lock_timeout_occurred;
2920-
bool stmt_timeout_occurred;
2921-
29222925
/*
2923-
* Don't allow query cancel interrupts while reading input from the
2924-
* client, because we might lose sync in the FE/BE protocol. (Die
2925-
* interrupts are OK, because we won't read any further messages from
2926-
* the client in that case.)
2926+
* Re-arm InterruptPending so that we process the cancel request
2927+
* as soon as we're done reading the message.
29272928
*/
2928-
if (QueryCancelHoldoffCount != 0)
2929-
{
2930-
/*
2931-
* Re-arm InterruptPending so that we process the cancel request
2932-
* as soon as we're done reading the message.
2933-
*/
2934-
InterruptPending = true;
2935-
return;
2936-
}
2929+
InterruptPending = true;
2930+
}
2931+
else if (QueryCancelPending)
2932+
{
2933+
bool lock_timeout_occurred;
2934+
bool stmt_timeout_occurred;
29372935

29382936
QueryCancelPending = false;
29392937

0 commit comments

Comments
 (0)