From: x4mmm@yandex-team.ru
To: Quentin de Metz <quentin@de.me.tz>
Cc: pgsql-novice@postgresql.org, amborodin@acm.org, aekorotkov@gmail.com,
 japinli@hotmail.com, zhjwpku@gmail.com
Subject: Re: SET transaction_timeout inside a transaction
Date: Sat, 20 Sep 2025 10:41:01 +0500
Message-ID: <34EA56AD-712D-4DEF-91B9-74FA1673A95D@yandex-team.ru>
In-Reply-To: <554670a7-7560-4d18-8ecb-8518fddf2b9d@app.fastmail.com>
References: <554670a7-7560-4d18-8ecb-8518fddf2b9d@app.fastmail.com>
MIME-Version: 1.0
Content-Type: text/plain; markup=markdown
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/34EA56AD-712D-4DEF-91B9-74FA1673A95D%40yandex-team.ru>
Precedence: bulk


On 20 Sep 2025, at 1:12, Quentin de Metz wrote:

> It appears that changing the transaction_timeout when inside a transact=
ion does not work as expected.
>
> Running the following script on master:
>
> SET transaction_timeout =3D '1s';
> BEGIN;
> SET transaction_timeout =3D '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 =3D 0" before each override=
=2E But this resets the timer, which may not be aligned with this paramet=
er'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 transactio=
n_timeout and set new time budget. Personally, I don't like it either. Bu=
t it did not seem a good idea to forbid resetting timeout at all or to fo=
rbid setting it amid of a transaction: we needed both this functionalitie=
s for "SET transaction_timeout =3D x;" to work.

It's hard to change anything radically in shipped feature. But, if possib=
le, please, tell more about usage patterns beyond pg_sleep(), maybe our a=
ssumptions were not accurate enough and we could do better in future.


Best regards, Andrey Borodin.