Re: Transaction timeout
Junwang Zhao <zhjwpku@gmail.com>
From: Junwang Zhao <zhjwpku@gmail.com>
To: Thomas wen <Thomas_valentine_365@outlook.com>
Cc: "Andrey M. Borodin" <x4mmm@yandex-team.ru>, Japin Li <japinli@hotmail.com>, 邱宇航 <iamqyh@gmail.com>, Fujii Masao <masao.fujii@oss.nttdata.com>, 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>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2023-12-20T02:35:16Z
Lists: pgsql-hackers
On Wed, Dec 20, 2023 at 9:58 AM Thomas wen <Thomas_valentine_365@outlook.com> wrote: > > Hi Junwang Zhao > #should we invalidate lock_timeout? Or maybe just document this. > I think you mean when lock_time is greater than trasaction-time invalidate lock_timeout or needs to be logged ? > I mean the interleaving of the gucs, which is lock_timeout and the new introduced transaction_timeout, if lock_timeout >= transaction_timeout, seems no need to enable lock_timeout. > > > > Best whish > ________________________________ > 发件人: Junwang Zhao <zhjwpku@gmail.com> > 发送时间: 2023年12月20日 9:48 > 收件人: Andrey M. Borodin <x4mmm@yandex-team.ru> > 抄送: Japin Li <japinli@hotmail.com>; 邱宇航 <iamqyh@gmail.com>; Fujii Masao <masao.fujii@oss.nttdata.com>; 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>; pgsql-hackers@lists.postgresql.org <pgsql-hackers@lists.postgresql.org> > 主题: Re: Transaction timeout > > On Tue, Dec 19, 2023 at 10:51 PM Junwang Zhao <zhjwpku@gmail.com> wrote: > > > > On Tue, Dec 19, 2023 at 6:27 PM Andrey M. Borodin <x4mmm@yandex-team.ru> wrote: > > > > > > > > > > > > > On 19 Dec 2023, at 13:26, Andrey M. Borodin <x4mmm@yandex-team.ru> wrote: > > > > > > > > I don’t have Windows machine, so I hope CF bot will pick this. > > > > > > I used Github CI to produce version of tests that seems to be is stable on Windows. > > > Sorry for the noise. > > > > > > > > > Best regards, Andrey Borodin. > > > > + <para> > > + If <varname>transaction_timeout</varname> is shorter than > > + <varname>idle_in_transaction_session_timeout</varname> or > > <varname>statement_timeout</varname> > > + <varname>transaction_timeout</varname> will invalidate longer timeout. > > + </para> > > > > When transaction_timeout is *equal* to idle_in_transaction_session_timeout > > or statement_timeout, idle_in_transaction_session_timeout and statement_timeout > > will also be invalidated, the logic in the code seems right, though > > this document > > is a little bit inaccurate. > > > <para> > Unlike <varname>statement_timeout</varname>, this timeout can only occur > while waiting for locks. Note that if > <varname>statement_timeout</varname> > is nonzero, it is rather pointless to set > <varname>lock_timeout</varname> to > the same or larger value, since the statement timeout would always > trigger first. If <varname>log_min_error_statement</varname> is set to > <literal>ERROR</literal> or lower, the statement that timed out will be > logged. > </para> > > There is a note about statement_timeout and lock_timeout, set both > and lock_timeout >= statement_timeout is pointless, but this logic seems not > implemented in the code. I am wondering if lock_timeout >= transaction_timeout, > should we invalidate lock_timeout? Or maybe just document this. > > > -- > > Regards > > Junwang Zhao > > > > -- > Regards > Junwang Zhao > > -- Regards Junwang Zhao
Commits
-
Add TAP tests for timeouts
- eeefd4280f6e 17.0 landed
-
Remove flaky isolation tests for timeouts
- a661bf7b0f56 17.0 landed
-
Followup fixes for transaction_timeout
- bf82f43790a6 17.0 landed
-
Introduce transaction_timeout
- 51efe38cb92f 17.0 landed
-
On systems that have setsid(2) (which should be just about everything except
- 3ad0728c817b 8.2.0 cited