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

Hi Alvaro, Chao,

Attached is v3. The code is the same as v2, with two additions.

1. The comment in RepackWorkerMain() now says why only lock_timeout and
transaction_timeout are passed. lock_timeout is armed by any lock wait,
and transaction_timeout by StartTransaction(). Both can fire in the
worker: the wait for older transactions in the snapshot builder is a
lock wait, and the worker's transaction spans the whole command.
statement_timeout and idle_in_transaction_session_timeout are only
armed by the command loop in PostgresMain(), which a background worker
never runs. I hope that answers Chao's question without touching
autovacuum.

2. A lock_timeout on the table owner role
does not reach the worker, and one set in the REPACK session does.
It fails on unpatched master and passes with 0001.

I expect this to be common in production, since a database- or
role-level lock_timeout is a normal setting. As REPACK (CONCURRENTLY)
is new in PG19, I suggest adding this to the open items and fixing it
before release.

Thanks,
Shihao