Re: transaction_timeout is not enforced during ClientWrite

From: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
To: Jingtang Zhang <mrdrivingduck(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, 邱宇航 <iamqyh(at)gmail(dot)com>
Subject: Re: transaction_timeout is not enforced during ClientWrite
Date: 2026-11-13 10:50:10
Message-ID: CAN4CZFNBS3uvMEMQHtM_x2zhui-5EnH3TkzJQKOuzFJXNUShWw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello

This seems to be a real issue, but isn't the patch incomplete?

It works if the timer fires while the backend is already blocked in
the write, but if the client has already stopped reading and the timer
fires while the backend is still doing something else,
ProcessInterrupts() clears TransactionTimeoutPending and raises the
FATAL, then pq_flush() blocks. At that point nothing is pending for
ProcessClientWriteInterrupt() to act on, so we wait forever, and the
transaction is only aborted later in proc_exit().

Repro is simple, a client that sends this as a simple query and never
reads anything:

psql -X -At -v FETCH_COUNT=1 -c "BEGIN; SET LOCAL
transaction_timeout='2s'; SELECT CASE WHEN g <= 25 THEN
repeat('x',8000) ELSE pg_sleep(6)::text END FROM generate_series(1,26)
g;" | sleep 25

(The row count has to fill the socket buffer almost, but not completely)

With a LOCK TABLE in the transaction, the lock is also still held
after the FATAL and blocks other sessions.

In response to

Browse pgsql-hackers by date

  From Date Subject
Previous Message vignesh C 2026-11-13 10:41:53 Re: Hash index: stop registering pin-only bucket pages in WAL (remove REGBUF_NO_CHANGE)