On Thu, 18 Jun 2026 at 06:37, Michael Paquier <[email protected]> wrote: > >> 3) An issue in StandbyAcquireAccessExclusiveLock() > > <snip> > > > > I'm not sure how to solve this correctly; I think ideally the > > StandbyAcquireAccessExclusiveLock() hash code would be wrapped by a > > critical section, but I'm not 100% sure if that will be a sufficient > > approach; and it'd definitely need some code to allow the various > > hashmaps' memctxs to alloc during critical sections. > > Not checked this one yet.
I found that the attached patch v3 solves that issue. The assert fires because we link the lock into the transaction's exclusive locks ahead of actually having acquired the lock, and when that lock acquisition fails, as part of the error handling we hit StartupProcExit->ShutdownRecoveryTransactionEnvironment->StandbyReleaseAllLocks, which causes this assertion failure because the lock was not taken by this backend. By moving StandbyAcquireAccessExclusiveLock's LockAcquire ahead of when it links the lock to the transaction, the local data structure doesn't know to clean up the lock until after it's acquired, so failure in that process won't make error cleanup try to clean up the lock. Kind regards, Matthias van de Meent Databricks (https://www.databricks.com)
v3-0001-IPC-standby-keep-better-track-of-taken-locks.patch
Description: Binary data
