Re: Transaction timeout - Mailing list pgsql-hackers

From Japin Li
Subject Re: Transaction timeout
Date
Msg-id ME3P282MB3166A01CE3BC1B8B9C846A75B67C2@ME3P282MB3166.AUSP282.PROD.OUTLOOK.COM
Whole thread Raw
In response to Re: Transaction timeout  ("Andrey M. Borodin" <x4mmm@yandex-team.ru>)
Responses Re: Transaction timeout
List pgsql-hackers
On Tue, 30 Jan 2024 at 14:22, Andrey M. Borodin <x4mmm@yandex-team.ru> wrote:
>> On 26 Jan 2024, at 19:58, Japin Li <japinli@hotmail.com> wrote:
>>
>> Thanks for updating the patch.  Here are some comments for v24.
>>
>> +       <para>
>> +        Terminate any session that spans longer than the specified amount of
>> +        time in transaction. The limit applies both to explicit transactions
>> +        (started with <command>BEGIN</command>) and to implicitly started
>> +        transaction corresponding to single statement. But this limit is not
>> +        applied to prepared transactions.
>> +        If this value is specified without units, it is taken as milliseconds.
>> +        A value of zero (the default) disables the timeout.
>> +       </para>
>> The sentence "But this limit is not applied to prepared transactions" is redundant,
>> since we have a paragraph to describe this later.
> Fixed.
>>
>> +
>> +       <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>
>> +
>>
>> Since we are already try to disable the timeouts, should we try to disable
>> them even if they are equal.
>
> Well, we disable timeouts on equality. Fixed docs.
>
>>
>> +
>> +       <para>
>> +        Prepared transactions are not subject for this timeout.
>> +       </para>
>>
>> Maybe wrap this with <note> is a good idea.
> Done.
>

Thanks for updating the patch.  LGTM.

If there is no other objections, I'll change it to ready for committer
next Monday.



pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: Improve WALRead() to suck data directly from WAL buffers when possible
Next
From: Alvaro Herrera
Date:
Subject: Re: Improve WALRead() to suck data directly from WAL buffers when possible