Re: Adding REPACK [concurrently]

On Wed, Apr 8, 2026 at 1:54 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> Hi,
>
> On 2026-04-07 00:22:32 +0200, Alvaro Herrera wrote:
> > From 4303eea0a72408183f9f5afcf8d2801df20f8ffe Mon Sep 17 00:00:00 2001
> > From: Antonin Houska <ah(at)cybertec(dot)at>
> > Date: Wed, 1 Apr 2026 17:35:47 +0200
> > Subject: [PATCH v56 3/3] Error out any process that would block at REPACK
> >
> > Any process waiting on REPACK to release its lock would actually cause
> > it to deadlock when it tries to upgrade its lock to AEL, losing all work
> > done to that point. We avoid this by teaching the deadlock detector to
> > raise an error when this condition is detected.
>
> I'm rather doubtful that that is ok.
>

Another possible idea is that after copying table_data to the new
table, we mark the old table as in_use_by_repack and release the
ShareUpdateExclusiveLock on the old table. Then the function
CheckTableNotInUse() should be updated to give an ERROR if the table
is marked as in_use_by_repack. Now, acquiring AEL by repack
(concurrently) should be safe because all concurrent DDLs should be
errored out due to flag in_use_by_repack. Can this address the problem
we are worried about the lock upgrade?

--
With Regards,
Amit Kapila.