Feedback-ID: id4a34324:Fastmail
Date: Thu, 9 Apr 2026 10:26:22 -0400
From: Andres Freund <andres@anarazel.de>
To: Mihail Nikalayeu <mihailnikalayeu@gmail.com>
Cc: Antonin Houska <ah@cybertec.at>, Amit Kapila <amit.kapila16@gmail.com>,
	Alvaro Herrera <alvherre@alvh.no-ip.org>,
 Srinath Reddy Sadipiralla <srinath2133@gmail.com>,
	Matthias van de Meent <boekewurm+postgres@gmail.com>,
 Pg Hackers <pgsql-hackers@lists.postgresql.org>,
	Robert Treat <rob@xzilla.net>
Subject: Re: Adding REPACK [concurrently]
Message-ID: <dstqatlculpdpsot5zlvons47nfyw7efht3p6qptwb2nivtsm3@ve3n2rqo64bu>
References: <202604062213.cgo352cdsgsm@alvherre.pgsql>
 <4n4q3preb3lgyhpzstebhux7b2aojhsw7gik4ivaznyggiezrs@lrznutssxlh2>
 <CAA4eK1JDrk9xiALd4DHnGLOkGDbObM59SXSBJyj0_1bNYbr5ng@mail.gmail.com>
 <gebmxzovxumuflknpua4r52tmuiam2odies2qlchzcl36cvphc@iz6bkpk64amp>
 <CADzfLwUed3gmARGbHnsDbrXsqPRW0b0VUtZxi5iNJj0LTC2fJA@mail.gmail.com>
 <CAA4eK1JDd9HBOtR5pgAptcQHpUyXROMe5jqBbLGBRBqn+rCYCg@mail.gmail.com>
 <9539.1775724194@localhost>
 <CADzfLwX78LmnZ6ZE3oSwuyw98WqY8g2HLHrSRRUBcgVQhMW=2Q@mail.gmail.com>
 <10697.1775726789@localhost>
 <CADzfLwWr-SQyVLkOryKpkL3yYLokuq2o-M3Ku1_XZrZMvxeWwg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CADzfLwWr-SQyVLkOryKpkL3yYLokuq2o-M3Ku1_XZrZMvxeWwg@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/dstqatlculpdpsot5zlvons47nfyw7efht3p6qptwb2nivtsm3%40ve3n2rqo64bu>
Precedence: bulk

Hi,

On 2026-04-09 16:06:17 +0200, Mihail Nikalayeu wrote:
> On Thu, Apr 9, 2026 at 11:26 AM Antonin Houska <ah@cybertec.at> wrote:
> > Sure, it's possible, but IMO the principal question is whether REPACK should
> > let VACUUM and DDLs error out, or just let them wait.
> 
> One more idea: instead of ERROR in CheckTableNotInUse in case of
> in_repack - just release the lock and retry a little later (by that
> time, the repack operation will likely have acquired the AEL).

I continue to think this approach has no chance of working.  Even if it
theoretically could, there are lots of paths to locking relations that do not
go through CheckTableNotInUse(), and we're not going to just route them all
through CheckTableNotInUse().

What CheckTableNotInUse() is for is to prevent DDL from changing the structure
of the table when it is still being referred to.  You can't just call
CheckTableNotInUse() from a LOCK TABLE - it would trigger wrong errors *ALL
THE TIME* because a LOCK TABLE does not need to error out just because there's
also a cursor on the table.


And it'd trigger lots of bogus errors. See the first example in
https://postgr.es/m/fpr4nsmyy3mpfrm2mijspr44dgol2cjeke5tyznb4btsznxsgx%40iifdbfe2wl63

S2 would get the lock and then error out due to the proposed check. Even
though there's no need for it.

Greetings,

Andres Freund