From: Antonin Houska <ah@cybertec.at>
To: Srinath Reddy Sadipiralla <srinath2133@gmail.com>
cc: Alvaro Herrera <alvherre@alvh.no-ip.org>,
    Mihail Nikalayeu <mihailnikalayeu@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]
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>
Comments: In-reply-to Srinath Reddy Sadipiralla <srinath2133@gmail.com>
   message dated "Tue, 31 Mar 2026 23:07:17 +0530."
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Tue, 31 Mar 2026 20:22:33 +0200
Message-ID: <238425.1774981353@localhost>
Archived-At: 
 <https://www.postgresql.org/message-id/238425.1774981353%40localhost>
Precedence: bulk

Srinath Reddy Sadipiralla <srinath2133@gmail.com> wrote:

> On Thu, Mar 26, 2026 at 1:42=E2=80=AFAM Alvaro Herrera <alvherre@alvh.no-=
ip.org> wrote:
>=20
>  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.=20
>=20
> 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 circ=
ular
> 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 upc=
oming
> AEL upgrade (e.g., an analytical SELECT or an idle-in-transaction holding=
 an AccessShareLock),
> but isn't waiting on REPACK at all?
>=20
> 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?

--=20
Antonin Houska
Web: https://www.cybertec-postgresql.com