On Fri, 19 Jun 2026 at 01:30, Michael Paquier <[email protected]> wrote: > > On Thu, Jun 18, 2026 at 05:27:57PM +0200, Matthias van de Meent wrote: > > 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. > > Yep, reordering these two actions would take care of the list > inconsistency where the startup process goes down following the ERROR > promoted to a FATAL. > > I have been fingering the idea of backpatching this fix for a few > minutes, actually, but discarded the idea at the end. It does not > require a random pattern to cause the failure, being actionable > through a combination of GUCs as Alexander has proved. Still, the > only consequence is an extra LOG entry telling that the lock is not > being tracked for non-assert builds. Confusing, OK, but not really > critical. > > Comments?
Because it fixes an assertion, I'd vote for backpatching; but because the case is handled safely without assertions I also wouldn't be upset if it wasn't backpatched. -Matthias
