On Wed, Apr 8, 2026 at 1:54 AM Andres Freund <[email protected]> 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 <[email protected]> > > 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.
