Обсуждение: SET transaction_timeout inside a transaction
Hello,
It appears that changing the transaction_timeout when inside a transaction does not work as expected.
Running the following script on master:
SET transaction_timeout = '1s';
BEGIN;
SET transaction_timeout = '3s';
SELECT pg_sleep(2);
Fails with the following:
FATAL: terminating connection due to transaction timeout
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
A workaround is to "SET transaction_timeout = 0" before each override. But this resets the timer, which may not be
alignedwith this parameter's intention.
Thank you,
Best regards,
Quentin de Metz
"Quentin de Metz" <quentin@de.me.tz> writes:
> It appears that changing the transaction_timeout when inside a transaction does not work as expected.
The effective value is whatever it was at transaction start, because
that's when the transaction timeout time is determined.
regards, tom lane
On Fri, 19 Sep 2025 22:12:59 +0200 "Quentin de Metz" <quentin@de.me.tz> wrote: > Hello, Hi, > It appears that changing the transaction_timeout when inside a > transaction does not work as expected. > > Running the following script on master: > > SET transaction_timeout = '1s'; > BEGIN; > SET transaction_timeout = '3s'; > SELECT pg_sleep(2); > > Fails with the following: > > FATAL: terminating connection due to transaction timeout > server closed the connection unexpectedly > This probably means the server terminated abnormally > before or while processing the request. > > A workaround is to "SET transaction_timeout = 0" before each > override. But this resets the timer, which may not be aligned with > this parameter's intention. You'll see what others will say, but it looks pretty logical to me to forbid an action on the one parameter your transaction directly depends on when inside it. Jean-Yves --
On Friday, September 19, 2025, Quentin de Metz <quentin@de.me.tz> wrote:
It appears that changing the transaction_timeout when inside a transaction does not work as expected.
Running the following script on master:
SET transaction_timeout = '1s';
BEGIN;
SET transaction_timeout = '3s';
SELECT pg_sleep(2);
It’s seems perfectly reasonable that as soon as a transaction begins it sets up a timer using the then-current value of transaction_timeout. And that changing the variable doesn’t affect any already established timers.
David J.
On 20 Sep 2025, at 1:12, Quentin de Metz wrote: > It appears that changing the transaction_timeout when inside a transaction does not work as expected. > > Running the following script on master: > > SET transaction_timeout = '1s'; > BEGIN; > SET transaction_timeout = '3s'; > SELECT pg_sleep(2); > > Fails with the following: > > FATAL: terminating connection due to transaction timeout > server closed the connection unexpectedly > This probably means the server terminated abnormally > before or while processing the request. > > A workaround is to "SET transaction_timeout = 0" before each override. But this resets the timer, which may not be alignedwith this parameter's intention. > Hi Quentin! Thanks for raising this, it's very good to hear more about usage patterns, it really helps to improve. Together with reviewers we did consider "extending" transaction timeout. But the problem is it promotes very unreliable codingpattern: adjusting time budget without checking how many time is already spent. Yes, if expectations of your transaction changed you can reset transaction_timeout and set new time budget. Personally, Idon't like it either. But it did not seem a good idea to forbid resetting timeout at all or to forbid setting it amid ofa transaction: we needed both this functionalities for "SET transaction_timeout = x;" to work. It's hard to change anything radically in shipped feature. But, if possible, please, tell more about usage patterns beyondpg_sleep(), maybe our assumptions were not accurate enough and we could do better in future. Best regards, Andrey Borodin.
Hi Andrey, The answers from the other participants in this thread make sense. My application has tooling to modify connection variables (e.g. statement_timeout) around specific queries, most of whichcan be set inside or outside the transaction with the same practical consequences. This is simply the first time we need to explicitly set a variable before opening the transaction. We'll make the necessarymodifications at the application layer. Regards, Quentin de Metz On Sat, Sep 20, 2025, at 07:41, x4mmm@yandex-team.ru wrote: > On 20 Sep 2025, at 1:12, Quentin de Metz wrote: > >> It appears that changing the transaction_timeout when inside a transaction does not work as expected. >> >> Running the following script on master: >> >> SET transaction_timeout = '1s'; >> BEGIN; >> SET transaction_timeout = '3s'; >> SELECT pg_sleep(2); >> >> Fails with the following: >> >> FATAL: terminating connection due to transaction timeout >> server closed the connection unexpectedly >> This probably means the server terminated abnormally >> before or while processing the request. >> >> A workaround is to "SET transaction_timeout = 0" before each override. But this resets the timer, which may not be alignedwith this parameter's intention. >> > > Hi Quentin! > > Thanks for raising this, it's very good to hear more about usage > patterns, it really helps to improve. > > Together with reviewers we did consider "extending" transaction > timeout. But the problem is it promotes very unreliable coding pattern: > adjusting time budget without checking how many time is already spent. > > Yes, if expectations of your transaction changed you can reset > transaction_timeout and set new time budget. Personally, I don't like > it either. But it did not seem a good idea to forbid resetting timeout > at all or to forbid setting it amid of a transaction: we needed both > this functionalities for "SET transaction_timeout = x;" to work. > > It's hard to change anything radically in shipped feature. But, if > possible, please, tell more about usage patterns beyond pg_sleep(), > maybe our assumptions were not accurate enough and we could do better > in future. > > > Best regards, Andrey Borodin.