Re: Transaction timeout

x4mmm@yandex-team.ru

From: "Andrey M. Borodin" <x4mmm@yandex-team.ru>
To: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: Andrey Borodin <amborodin86@gmail.com>, Andres Freund <andres@anarazel.de>, Michael Paquier <michael.paquier@gmail.com>, Nikolay Samokhvalov <samokhvalov@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2023-09-06T11:32:33Z
Lists: pgsql-hackers
Thanks for looking into this!

> On 6 Sep 2023, at 13:16, Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
> 
> While testing v4 patch, I noticed it doesn't handle the COMMIT AND CHAIN case correctly.
> When COMMIT AND CHAIN is executed, I believe the transaction timeout counter should reset
> and start from zero with the next transaction. However, it appears that the current
> v4 patch doesn't reset the counter in this scenario. Can you confirm this?
Yes, I was not aware of this feature. I'll test and fix this.

> With the v4 patch, I found that timeout errors no longer occur during the idle in
> transaction phase. Instead, they occur when the next statement is executed. Is this
> the intended behavior?
AFAIR I had been testing that behaviour of "idle in transaction" was intact. I'll check that again.

> I thought some users might want to use the transaction timeout
> feature to prevent prolonged transactions and promptly release resources (e.g., locks)
> in case of a timeout, similar to idle_in_transaction_session_timeout.
Yes, this is exactly how I was expecting the feature to behave: empty up max_connections slots for long-hanging transactions.

Thanks for your findings, I'll check and post new version!


Best regards, Andrey Borodin.


Commits

  1. Add TAP tests for timeouts

  2. Remove flaky isolation tests for timeouts

  3. Followup fixes for transaction_timeout

  4. Introduce transaction_timeout

  5. On systems that have setsid(2) (which should be just about everything except