> On Sep 12, 2026, at 10:57, Chao Li <[email protected]> wrote:
>
>
>
>> On Sep 12, 2026, at 00:33, Álvaro Herrera <[email protected]> wrote:
>>
>> On 2026-Sep-10, Chao Li wrote:
>>
>>>> On Sep 10, 2026, at 11:21, shihao zhong <[email protected]> wrote:
>>
>>>> Done in v2, through the DSM segment the worker already attaches to.
>>
>> I think this is pretty reasonable.
>>
>>> Auto-vacuum explicitly overrides all four settable session timeouts
>>> (statement_timeout, transaction_timeout, lock_timeout, and
>>> idle_in_transaction_session_timeout) to zero, while this worker only
>>> handles the latter two. I understand that statement_timeout and
>>> idle_in_transaction_session_timeout are probably never armed by this
>>> worker, so functionally they may not need special handling.
>>
>> Hmm, but REPACK is not autovacuum; it's quite different in fact, in that
>> REPACK is intended to always be invoked manually, while autovacuum runs
>> on its own. On the other hand, because REPACK refuses to run in a
>> transaction block, transaction_timeout and
>> idle_in_transaction_session_timeout don't really apply, so I'm not
>> seeing the potential for problems.
>>
>
> Yeah, I fully understood the difference. My concern was only about the
> inconsistency.
>
>>> My concern is that the inconsistency might lead to confusion to future
>>> readers. Does it make sense to either remove those two from
>>> auto-vacuum worker or set them to repack worker as well?
>>
>> I decidedly don't want to touch autovacuum. Although I'm not sure I see
>> the reason why the transaction-based timeouts are relevant for
>> autovacuum.
>>
>
> That was actually my concern. The fact that this raised the question of why
> autovacuum resets those timeouts suggests that the inconsistency can be
> confusing to readers.
>
> I agree we don't need to touch autovacuum in this patch. Does it make sense
> to remove those unnecessary timeout resets from autovacuum by a separate
> patch?
>
Say, if another worker is added in the future, the author may look at both the
autovacuum and repack workers as references, notice that they reset different
sets of timeouts, and then have to spend time figuring out which behavior to
follow and why.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
