public inbox for [email protected]
help / color / mirror / Atom feedFrom: Andres Freund <[email protected]>
To: Amit Kapila <[email protected]>
Cc: Alvaro Herrera <[email protected]>
Cc: Mihail Nikalayeu <[email protected]>
Cc: Antonin Houska <[email protected]>
Cc: Srinath Reddy Sadipiralla <[email protected]>
Cc: Matthias van de Meent <[email protected]>
Cc: Pg Hackers <[email protected]>
Cc: Robert Treat <[email protected]>
Subject: Re: Adding REPACK [concurrently]
Date: Wed, 8 Apr 2026 13:22:41 -0400
Message-ID: <gebmxzovxumuflknpua4r52tmuiam2odies2qlchzcl36cvphc@iz6bkpk64amp> (raw)
In-Reply-To: <CAA4eK1JDrk9xiALd4DHnGLOkGDbObM59SXSBJyj0_1bNYbr5ng@mail.gmail.com>
References: <CADzfLwWFr9h_+cbSQvPpdxgLbVL5wwxFRx21ezNvLYgJM=FVCQ@mail.gmail.com>
<[email protected]>
<4n4q3preb3lgyhpzstebhux7b2aojhsw7gik4ivaznyggiezrs@lrznutssxlh2>
<CAA4eK1JDrk9xiALd4DHnGLOkGDbObM59SXSBJyj0_1bNYbr5ng@mail.gmail.com>
Hi,
On 2026-04-08 14:05:49 +0530, Amit Kapila wrote:
> On Wed, Apr 8, 2026 at 1:54 AM Andres Freund <[email protected]> wrote:
> > On 2026-04-07 00:22:32 +0200, Alvaro Herrera wrote:
> > > From 4303eea0a72408183f9f5afcf8d2801df20f8ffe Mon Sep 17 00:00:00 2001
> > > From: Antonin Houska <[email protected]>
> > > Date: Wed, 1 Apr 2026 17:35:47 +0200
> > > Subject: [PATCH v56 3/3] Error out any process that would block at REPACK
> > >
> > > Any process waiting on REPACK to release its lock would actually cause
> > > it to deadlock when it tries to upgrade its lock to AEL, losing all work
> > > done to that point. We avoid this by teaching the deadlock detector to
> > > raise an error when this condition is detected.
> >
> > I'm rather doubtful that that is ok.
> >
>
> Another possible idea is that after copying table_data to the new
> table, we mark the old table as in_use_by_repack and release the
> ShareUpdateExclusiveLock on the old table. Then the function
> CheckTableNotInUse() should be updated to give an ERROR if the table
> is marked as in_use_by_repack. Now, acquiring AEL by repack
> (concurrently) should be safe because all concurrent DDLs should be
> errored out due to flag in_use_by_repack. Can this address the problem
> we are worried about the lock upgrade?
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.
And you need to wait for all pre-existing locks to have been released. That
doesn't really get easier by what you propose.
I don't think CheckTableNotInUse() would work anyway - don't we already hold
locks by the point we call it? And even if that were not the case, there are
several paths to locking relations that don't ever go anywhere near
CheckTableNotInUse().
Greetings,
Andres Freund
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Adding REPACK [concurrently]
In-Reply-To: <gebmxzovxumuflknpua4r52tmuiam2odies2qlchzcl36cvphc@iz6bkpk64amp>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox