StandbyAcquireAccessExclusiveLock doesn't necessarily

Поиск
Список
Период
Сортировка
От Tom Lane
Тема StandbyAcquireAccessExclusiveLock doesn't necessarily
Дата
Msg-id 6202.1536359835@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: StandbyAcquireAccessExclusiveLock doesn't necessarily  (Simon Riggs <simon@2ndquadrant.com>)
Re: StandbyAcquireAccessExclusiveLock doesn't necessarily  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: unaccent(text) fails depending on search_path (WAS: pg_upgradefails saying function unaccent(text) doesn't exist)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: unaccent(text) fails depending on search_path (WAS: pg_upgrade fails saying function unaccent(text) doesn't exist)