Hi, On one of the PostgreSQL instances we manage, we saw a transaction remain open for more than 15min with transaction_timeout set to 50s. The backend was waiting on ClientWrite. We couldn't tell whether the client or the network caused the stall, but I think the server should have closed the connection when the transaction timeout expired.
ProcessClientWriteInterrupt() only handles ProcDiePending while the socket write is blocked. I agree with the reasoning in the earlier discussion [1] that canceling a query mid-write and then keeping the connection open can leave the protocol out of sync. Since we decided that transaction_timeout should terminate the session with FATAL [2], is there any design reason to defer handling it while a client write is blocked? The attached patch lets ProcessClientWriteInterrupt() use the existing termination path for a pending transaction timeout. In ProcessInterrupts(), it moves transaction timeout handling immediately after ProcDiePending so a pending query cancel cannot raise a recoverable error first. Thoughts? --- Regards, Jingtang [1] https://www.postgresql.org/message-id/CA%2BTgmoZiZQF5YFLTM_S7TWOy6UKO0639sxDWYOQMYgvHfZ_rMA%40mail.gmail.com [2] https://www.postgresql.org/message-id/ACC3312D-8218-4F30-8350-E8634BF1C5DC%40yandex-team.ru
v1-0001-Honor-transaction-timeout-during-blocked-client-writes.patch
Description: Binary data
