回复: Transaction timeout - Mailing list pgsql-hackers

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