On Tue, Mar 31, 2026 at 11:54 PM Alvaro Herrera <[email protected]> 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? -- With Regards, Amit Kapila.
