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.
