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

> 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?

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/