Feedback-ID: id4a34324:Fastmail
Date: Thu, 9 Apr 2026 10:13:26 -0400
From: Andres Freund <andres@anarazel.de>
To: Mihail Nikalayeu <mihailnikalayeu@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>,
	Alvaro Herrera <alvherre@alvh.no-ip.org>, Antonin Houska <ah@cybertec.at>,
	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: <zefg3dww5q5iayo46mdiqgsewtwx3qv3jp2utzj5ucxdc7isvu@3q7szybdkmdx>
References: 
 <CADzfLwWFr9h_+cbSQvPpdxgLbVL5wwxFRx21ezNvLYgJM=FVCQ@mail.gmail.com>
 <202604062213.cgo352cdsgsm@alvherre.pgsql>
 <4n4q3preb3lgyhpzstebhux7b2aojhsw7gik4ivaznyggiezrs@lrznutssxlh2>
 <CAA4eK1JDrk9xiALd4DHnGLOkGDbObM59SXSBJyj0_1bNYbr5ng@mail.gmail.com>
 <gebmxzovxumuflknpua4r52tmuiam2odies2qlchzcl36cvphc@iz6bkpk64amp>
 <CADzfLwUed3gmARGbHnsDbrXsqPRW0b0VUtZxi5iNJj0LTC2fJA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CADzfLwUed3gmARGbHnsDbrXsqPRW0b0VUtZxi5iNJj0LTC2fJA@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/zefg3dww5q5iayo46mdiqgsewtwx3qv3jp2utzj5ucxdc7isvu%403q7szybdkmdx>
Precedence: bulk

Hi,

On 2026-04-09 01:36:00 +0200, Mihail Nikalayeu wrote:
> Hello, Andres!
> 
> On Wed, Apr 8, 2026 at 7:22 PM Andres Freund <andres@anarazel.de> wrote:
> > I don't think this is a viable path.  You need to prevent any further lock
> > acquisitions on the relation to be able to swap it, not just conflicting DDL.
> 
> AFAIU, Amit's main idea is that we currently upgrade the lock instead
> of **releasing and re-acquiring** it because we fear DDL between those
> actions.

I got that, I just don't think it's going to work in any sort of way
reasonably well.

The fix here should be to make the system understand how to make lock upgrades
as safe as possible, not to hack around the corners.  For that you need to
teach the deadlock detector about all of this properly.


> > I don't think CheckTableNotInUse() would work anyway - don't we already hold
> > locks by the point we call it?
> 
> Yes, the DDL session already holds locks by the time
> CheckTableNotInUse is called - but is that really the problem? They
> will be released on error.

There's no guarantee they get there if it's done after the lock
acquisition. It can be part of a more complicated lock cycle.

Greetings,

Andres Freund