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?
--
Michael
