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

> On Sep 7, 2026, at 06:05, shihao zhong <zhong950419(at)gmail(dot)com> wrote:
>
> HI hackers,
>
> Running two REPACK (CONCURRENTLY) on one database with
> ALTER DATABASE ... SET lock_timeout = '5s', the second one fails:
>
> ERROR: canceling statement due to lock timeout
> CONTEXT: waiting for ShareLock on transaction 2076
> REPACK decoding worker
>
> The worker waits for the first REPACK's XID in the snapshot builder.
> It runs in its own session as the table owner, so the database-level
> lock_timeout applies to it, and SET lock_timeout = 0 in the REPACK
> session does not reach it.
>
> The attached patch turns the settable timeouts off in the worker, as
> autovacuum does. statement_timeout and cancel on the REPACK session
> still stop the whole command.

Seems reasonable to me. As you also mentioned in the code comment, auto-vacuum does the same thing.

>
> Separately, the wait itself means REPACK (CONCURRENTLY) runs are
> serialized. A PROC_IN_SAFE_IC-like flag could let the worker skip
> other REPACK transactions; I can look into that if there is interest.
>

Yeah, I think the PROC_IN_SAFE_IC-like flag is the key point here. Since multiple VACUUM FULL commands on different tables can run in parallel, having REPACK (CONCURRENTLY) operations serialized could make the feature less competitive. In practice, it is quite common to need to repack more than one table, so allowing independent REPACK operations to proceed in parallel seems worthwhile.

> Thanks,
> Shihao
> <0001-Force-timeouts-off-in-the-REPACK-CONCURRENTLY-decodi.patch><N1-repro.log>

The patch itself looks good to me. The PROC_IN_SAFE_IC-like flag enhancement could probably be discussed separately. I imagine that would be a larger feature?

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