Re: REPACK (CONCURRENTLY) decoding worker is canceled by lock_timeout

> On Sep 12, 2026, at 10:57, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
>
>
>
>> On Sep 12, 2026, at 00:33, Álvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:
>>
>> On 2026-Sep-10, Chao Li wrote:
>>
>>>> On Sep 10, 2026, at 11:21, shihao zhong <zhong950419(at)gmail(dot)com> 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/