On Fri, 19 Jun 2026 at 01:30, Michael Paquier <michael@paquier.xyz> 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
