Feedback-ID: id4a34324:Fastmail
Date: Thu, 9 Apr 2026 10:34:52 -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: <czy56lgv2knlzl2dgdyx32qqrrdhx3y4tmgv66t2ikvtju6o6z@bf63q2eumhu2>
References: <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>
 <dstqatlculpdpsot5zlvons47nfyw7efht3p6qptwb2nivtsm3@ve3n2rqo64bu>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <dstqatlculpdpsot5zlvons47nfyw7efht3p6qptwb2nivtsm3@ve3n2rqo64bu>
Archived-At: 
 <https://www.postgresql.org/message-id/czy56lgv2knlzl2dgdyx32qqrrdhx3y4tmgv66t2ikvtju6o6z%40bf63q2eumhu2>
Precedence: bulk

Hi,

On 2026-04-09 10:26:22 -0400, Andres Freund wrote:
> 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.

Before you protest that you could just let the non-DDL operation have its
lock, sure, but that's an utterly terrible idea, because it will lead to more
and more work accumulating that then has to happen when the AEL is actually
held.

Greetings,

Andres Freund