MIME-Version: 1.0
References: 
 <CAFC+b6of6_poBQ6EgK8N49VQwAUYX=uLkHiU-TP7y+DamBD5TQ@mail.gmail.com>
 <202603311819.3gvgmupluxh2@alvherre.pgsql>
In-Reply-To: <202603311819.3gvgmupluxh2@alvherre.pgsql>
From: Amit Kapila <amit.kapila16@gmail.com>
Date: Wed, 1 Apr 2026 15:09:31 +0530
Message-ID: 
 <CAA4eK1K=214d_Ya8jqMJQHamKxQXu8pxHux_cT0Ew0-AeE4K5Q@mail.gmail.com>
Subject: Re: Adding REPACK [concurrently]
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Srinath Reddy Sadipiralla <srinath2133@gmail.com>,
 Mihail Nikalayeu <mihailnikalayeu@gmail.com>,
	Antonin Houska <ah@cybertec.at>,
 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/CAA4eK1K%3D214d_Ya8jqMJQHamKxQXu8pxHux_cT0Ew0-AeE4K5Q%40mail.gmail.com>
Precedence: bulk

On Tue, Mar 31, 2026 at 11:54=E2=80=AFPM Alvaro Herrera <alvherre@alvh.no-i=
p.org> wrote:
>
> On 2026-Mar-31, Srinath Reddy Sadipiralla wrote:
>
> > 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.Initially, I thought this cleanup
> > was expected behavior. But after seeing your solution to protect
> > REPACK from losing its transient table work, I thought it's "not
> > expected".
>
> Yeah.  Keep in mind that REPACK could have been running for many hours
> or even days before it reaches the point of acquiring its AEL lock to do
> the final swap; and it may well be critical work.  We do not want to
> lose it.  So whatever is waiting to obtain a lock on the table, or
> already has a lock on the table, has to yield.
>
> > If the goal is to prevent REPACK's work from being wasted, should we
> > error out the backend that is making REPACK wait during the final swap
> > phase? I am thinking of something conceptually similar to
> > ResolveRecoveryConflictWithLock, actively cancelling the conflicting
> > session to allow the AEL upgrade to proceed.
>
> Something like that might be appropriate, yeah.
>

What about if the blocking process is an autovacumm that is working to
prevent XID wraparound? I think we already avoid killing it in such
cases. BTW, one can say that cancelling a long-running report query
also wastes a lot of effort of the user generating such a report. Why
can't REPACK wait for such a select to finish instead of cancelling
it?

--=20
With Regards,
Amit Kapila.