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.
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"El miedo atento y previsor es la madre de la seguridad" (E. Burke)
