StandbyAcquireAccessExclusiveLock doesn't necessarily - Mailing list pgsql-hackers

From Tom Lane
Subject StandbyAcquireAccessExclusiveLock doesn't necessarily
Date
Msg-id 6202.1536359835@sss.pgh.pa.us
Whole thread Raw
Responses Re: StandbyAcquireAccessExclusiveLock doesn't necessarily  (Simon Riggs <simon@2ndquadrant.com>)
Re: StandbyAcquireAccessExclusiveLock doesn't necessarily  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: unaccent(text) fails depending on search_path (WAS: pg_upgradefails saying function unaccent(text) doesn't exist)
Next
From: Tom Lane
Date:
Subject: Re: unaccent(text) fails depending on search_path (WAS: pg_upgrade fails saying function unaccent(text) doesn't exist)