On 2026-Sep-06, shihao zhong wrote: > 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.
Hmm, but there's no practical effect here, right? If it doesn't die because of this particular timeout, it will fail due to some other timeout. We just don't have an implementation that allows to run two concurrent REPACK CONCURRENTLY. Will you later suggest to turn off statement_timeout during REPACK? > 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. Antonin Houska has a patch which would probably benefit from your review. https://postgr.es/m/108776.1784105248@localhost -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "Hay dos momentos en la vida de un hombre en los que no debería especular: cuando puede permitírselo y cuando no puede" (Mark Twain)
