Re: StandbyAcquireAccessExclusiveLock doesn't necessarily

Commit 37c54863c removed the code in StandbyAcquireAccessExclusiveLock
that checked the return value of LockAcquireExtended.  AFAICS this was
flat out wrong, because it's still passing reportMemoryError = false
to LockAcquireExtended, meaning there are still cases where
LOCKACQUIRE_NOT_AVAIL will be returned.  In such a situation, the
startup process would believe it had acquired exclusive lock even
though it hadn't, with potentially dire consequences.

While we could certainly put back a test there, it's not clear to me
that it could do anything more useful than erroring out, at least
not without largely reverting 37c54863c.

So my inclination is to remove the reportMemoryError = false parameter,
and just let an error happen in the unlikely situation that we hit OOM
for the lock table.

That would allow this code to not use LockAcquireExtended at all.
Indeed, I'd be rather tempted to remove that parameter from
LockAcquireExtended altogether, as I don't believe it's either
particularly useful, or at all well tested, or even testable.