Re: inefficient loop in StandbyReleaseLockList()

Поиск
Список
Период
Сортировка
От Bossart, Nathan
Тема Re: inefficient loop in StandbyReleaseLockList()
Дата
Msg-id 0108A03D-FF2B-4CBC-933B-E047CD975158@amazon.com
обсуждение исходный текст
Ответ на Re: inefficient loop in StandbyReleaseLockList()  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: inefficient loop in StandbyReleaseLockList()  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 10/28/21, 11:53 PM, "Michael Paquier" <michael@paquier.xyz> wrote:
> On Thu, Oct 28, 2021 at 04:52:48PM -0700, Andres Freund wrote:
>> I suspect the reverse lock order release could be tad faster. But I probably
>> wouldn't change it either - I was more thinking of some of the other cases
>> that deleted the first element, here it's a bit harder to know wether there's
>> a chance of a CFI() or such.
>
> Actually, as the list of recovery locks is saved in TopMemoryContext,
> wouldn't it be better to keep a per-cell deletion of the list, which
> would mean that we'd better do the operation in the reverse order to
> make things faster with the new list implementation?  But that's what
> Andres points at with CFIs in the middle of one list of the hash table
> processed?

Hm.  IIUC anything bad enough to cause the startup process to break
out of the StandbyReleaseLockList() loop will also cause the entire
process to be restarted.  I'm not seeing any risk of reusing a half-
released lock list.  I might be misunderstanding the concern, though.

Nathan


В списке pgsql-hackers по дате отправления:

Предыдущее
От: wenjing
Дата:
Сообщение: Re: [Proposal] Global temporary tables
Следующее
От: Jacob Champion
Дата:
Сообщение: Re: [PATCH] Support pg_ident mapping for LDAP