agora inbox for pgsql-hackers@postgresql.org
help / color / mirror / Atom feedFrom: Antonin Houska <ah@cybertec.at>
To: Srinath Reddy Sadipiralla <srinath2133@gmail.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Mihail Nikalayeu <mihailnikalayeu@gmail.com>
Cc: Matthias van de Meent <boekewurm+postgres@gmail.com>
Cc: Pg Hackers <pgsql-hackers@lists.postgresql.org>
Cc: Robert Treat <rob@xzilla.net>
Subject: Re: Adding REPACK [concurrently]
Date: Tue, 31 Mar 2026 20:22:33 +0200
Message-ID: <238425.1774981353@localhost> (raw)
In-Reply-To: <CAFC+b6of6_poBQ6EgK8N49VQwAUYX=uLkHiU-TP7y+DamBD5TQ@mail.gmail.com>
References: <CAFC+b6pK9ogeSpMA8hg18XhC1eNPcsKWBwoC5OySXi4iTxwtRw@mail.gmail.com>
<202603252005.quy5h4oipoxd@alvherre.pgsql>
<CAFC+b6of6_poBQ6EgK8N49VQwAUYX=uLkHiU-TP7y+DamBD5TQ@mail.gmail.com>
Srinath Reddy Sadipiralla <srinath2133@gmail.com> wrote:
> On Thu, Mar 26, 2026 at 1:42 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
> As for lock upgrade, I wonder if the best way to handle this isn't to
> hack the deadlock detector so that it causes any *other* process to die,
> if they detect that they would block on REPACK. Arguably there's
> nothing that you can do to a table while its undergoing REPACK
> CONCURRENTLY; any alterations would have to wait until the repacking is
> compelted. We can implement that idea simply enough, as shown in this
> crude prototype.
>
> After testing this, I observed that it solves the scenario where a query is waiting
> on REPACK. For example, if a DROP TABLE requests an AEL and queues
> behind REPACK's ShareUpdateExclusiveLock, the deadlock detector comes
> when REPACK tries to upgrade to AEL, killing the DROP to prevent the circular
> queue deadlock, But the case I originally mentioned [1] was the reverse: what
> happens if a transaction already holds a lock that conflicts with the upcoming
> AEL upgrade (e.g., an analytical SELECT or an idle-in-transaction holding an AccessShareLock),
> but isn't waiting on REPACK at all?
>
> In this case, there's no circular wait. The deadlock detector never fires. REPACK
> simply queues behind the SELECT, eventually hits its lock_timeout, aborts and
> cleans up.
Why should the user set non-zero lock_timeout before running REPACK?
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
view thread (416+ messages) latest in thread
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: pgsql-hackers@postgresql.org
Cc: ah@cybertec.at, srinath2133@gmail.com, alvherre@alvh.no-ip.org, mihailnikalayeu@gmail.com, boekewurm+postgres@gmail.com, pgsql-hackers@lists.postgresql.org, rob@xzilla.net
Subject: Re: Adding REPACK [concurrently]
In-Reply-To: <238425.1774981353@localhost>
* 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