From: Antonin Houska <ah@cybertec.at>
To: Andres Freund <andres@anarazel.de>
cc: Mihail Nikalayeu <mihailnikalayeu@gmail.com>,
    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]
In-reply-to: <aixbxaenmbvsaarnxpagkgajv25zpc4ogo6gwv7lr7bbrh3arp@xom2lyvdgccf>
References: <4n4q3preb3lgyhpzstebhux7b2aojhsw7gik4ivaznyggiezrs@lrznutssxlh2>
 <CAA4eK1JDrk9xiALd4DHnGLOkGDbObM59SXSBJyj0_1bNYbr5ng@mail.gmail.com>
 <gebmxzovxumuflknpua4r52tmuiam2odies2qlchzcl36cvphc@iz6bkpk64amp>
 <CADzfLwUed3gmARGbHnsDbrXsqPRW0b0VUtZxi5iNJj0LTC2fJA@mail.gmail.com>
 <CAA4eK1JDd9HBOtR5pgAptcQHpUyXROMe5jqBbLGBRBqn+rCYCg@mail.gmail.com>
 <9539.1775724194@localhost>
 <fpr4nsmyy3mpfrm2mijspr44dgol2cjeke5tyznb4btsznxsgx@iifdbfe2wl63>
 <CADzfLwURKVNQ++Dpi7bjoGfj-8pchDQEVex3eWBx0NCYn6TbDQ@mail.gmail.com>
 <rr2hcc5c7cm3xpbi2bniduhvq7pko4fnmykdui2wns2pvowk4n@nod4copoefzs>
 <112208.1776173876@localhost>
 <aixbxaenmbvsaarnxpagkgajv25zpc4ogo6gwv7lr7bbrh3arp@xom2lyvdgccf>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
   message dated "Tue, 14 Apr 2026 09:58:55 -0400."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <25513.1776264611.1@localhost>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 15 Apr 2026 16:50:11 +0200
Message-ID: <25514.1776264611@localhost>
Archived-At: 
 <https://www.postgresql.org/message-id/25514.1776264611%40localhost>
Precedence: bulk

Andres Freund <andres@anarazel.de> wrote:

> On 2026-04-14 15:37:56 +0200, Antonin Houska wrote:
> > Andres Freund <andres@anarazel.de> wrote:
> > =

> > > On 2026-04-12 15:31:20 +0200, Mihail Nikalayeu wrote:
> > > > Instead of cancelling the backend entered the deadlock detector - =
it
> > > > cancel some another (nearest hard edge) until it is possible to ge=
t the
> > > > lock (either by
> > > > reordering or directly).
> > > =

> > > I don't think that's as good.  The problem is that that way you're o=
nly
> > > detecting the deadlocks once they have materialized (i.e. once repac=
k actually
> > > does the lock upgrade), rather than cancelling when we know that the=
 problem
> > > starts.
> > =

> > This is my hack that tries to do that.
> =

> I still think this needs to be in the deadlock detector.  The lock cycle=
 just
> needs to be a bit more complicated for a hack in JoinWaitQueue not to wo=
rk.
> There's no guarantee that the wait that triggers the deadlock is actuall=
y on
> the relation being repacked.

ok, I see.

I thought of a "hypothetical graph", which would include the to-be-granted
lock, but the major issue is that it will not work correctly without the
locking the LMGR's LW locks we do in CheckDeadLock():

    for (i =3D 0; i < NUM_LOCK_PARTITIONS; i++)
        LWLockAcquire(LockHashPartitionLockByIndex(i), LW_EXCLUSIVE);

And obviously, doing this each time we want to insert a lock into the queu=
e
would be bad for performance. It's even mentioned in the storage/lmgr/READ=
ME
that the current approach is optimistic, so I think that major rework woul=
d be
needed if we wanted to entirely avoid waiting that leads to deadlock.

The approach proposed by Mihail [1] seems the least problematic to me, and
something like that occurred to me when I thought about the problem the fi=
rst
time. However, when we wake up the other processes in order to run the
deadlock detection, they should do that immediately. I've got no good idea
about implementation at the moment, since latch can be set for unrelated
reasons. (Besides that, I have some more questions about this patch, which=
 I
can post separately.)


[1] https://www.postgresql.org/message-id/CADzfLwURKVNQ%2B%2BDpi7bjoGfj-8p=
chDQEVex3eWBx0NCYn6TbDQ%40mail.gmail.com

-- =

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