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

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.

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

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/