Srinath Reddy Sadipiralla <[email protected]> wrote: > On Thu, Mar 26, 2026 at 1:42 AM Alvaro Herrera <[email protected]> > wrote: > > As for lock upgrade, I wonder if the best way to handle this isn't to > hack the deadlock detector so that it causes any *other* process to die, > if they detect that they would block on REPACK. Arguably there's > nothing that you can do to a table while its undergoing REPACK > CONCURRENTLY; any alterations would have to wait until the repacking is > compelted. We can implement that idea simply enough, as shown in this > crude prototype. > > After testing this, I observed that it solves the scenario where a query is > waiting > on REPACK. For example, if a DROP TABLE requests an AEL and queues > behind REPACK's ShareUpdateExclusiveLock, the deadlock detector comes > when REPACK tries to upgrade to AEL, killing the DROP to prevent the circular > queue deadlock, But the case I originally mentioned [1] was the reverse: what > happens if a transaction already holds a lock that conflicts with the upcoming > AEL upgrade (e.g., an analytical SELECT or an idle-in-transaction holding an > AccessShareLock), > but isn't waiting on REPACK at all? > > 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.
Why should the user set non-zero lock_timeout before running REPACK? -- Antonin Houska Web: https://www.cybertec-postgresql.com
