Feedback-ID: ie3de48e3:Fastmail
Date: Tue, 8 Sep 2026 09:31:01 +0200
From: =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de>
To: shihao zhong <zhong950419@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: REPACK (CONCURRENTLY) decoding worker is canceled by lock_timeout
Message-ID: <ap-4gDuPgFoudT-m@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAGRkXqTYaBjFvjtjPb1+=sZWvt93=2c472bmM+xdG7w9ZvAydA@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/ap-4gDuPgFoudT-m%40alvherre.pgsql>
Precedence: bulk

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)