Horton

Thread

  1. SET transaction_timeout inside a transaction

    Quentin de Metz <quentin@de.me.tz> — 2025-09-19T20:12:59Z

    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 aligned with this parameter's intention.

Thank you,
Best regards,

Quentin de Metz

  2. Re: SET transaction_timeout inside a transaction

    Tom Lane <tgl@sss.pgh.pa.us> — 2025-09-19T20:21:00Z

    "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

  3. Re: SET transaction_timeout inside a transaction

    Bzzzz <lazyvirus@gmx.com> — 2025-09-19T20:21:49Z

    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
--

  4. Re: SET transaction_timeout inside a transaction

    David G. Johnston <david.g.johnston@gmail.com> — 2025-09-19T20:24:18Z

    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.

  5. Re: SET transaction_timeout inside a transaction

    x4mmm@yandex-team.ru — 2025-09-20T05:41:01Z

    
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 aligned with 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.

  6. Re: SET transaction_timeout inside a transaction

    Quentin de Metz <quentin@de.me.tz> — 2025-09-25T14:29:50Z

    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 which can 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 necessary modifications 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 aligned with 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.