MIME-Version: 1.0
References: 
 <CADzfLwWFr9h_+cbSQvPpdxgLbVL5wwxFRx21ezNvLYgJM=FVCQ@mail.gmail.com>
 <202604062213.cgo352cdsgsm@alvherre.pgsql>
 <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>
In-Reply-To: <rr2hcc5c7cm3xpbi2bniduhvq7pko4fnmykdui2wns2pvowk4n@nod4copoefzs>
From: Mihail Nikalayeu <mihailnikalayeu@gmail.com>
Date: Sun, 12 Apr 2026 16:58:31 +0200
Message-ID: 
 <CADzfLwVFtjBN6YFWV5ziZkxyq5_JaCapWPostwEwBTzQg=fPng@mail.gmail.com>
Subject: Re: Adding REPACK [concurrently]
To: Andres Freund <andres@anarazel.de>
Cc: Antonin Houska <ah@cybertec.at>, 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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CADzfLwVFtjBN6YFWV5ziZkxyq5_JaCapWPostwEwBTzQg%3DfPng%40mail.gmail.com>
Precedence: bulk

Hi!

On Sun, Apr 12, 2026 at 4:05=E2=80=AFPM Andres Freund <andres@anarazel.de> =
wrote:
> I don't think that's as good.  The problem is that that way you're only
> detecting the deadlocks once they have materialized (i.e. once repack act=
ually
> does the lock upgrade), rather than cancelling when we know that the prob=
lem
> starts.  Having sessions pointlessly blocked for many hours is bad.

O, I think I understand you now.
You propose to somehow mark SUEL as "going to become AEL, so, the
deadlock detector should treat it as such".
In that case LOCK TABLE should get some kind of "future deadlock detected".

Yep, that feels much better. I'll try to check that approach tomorrow.

Best regards,
Mikhail.