Re: Contention on LWLock buffer_content, due to SHARED lock(?)

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Contention on LWLock buffer_content, due to SHARED lock(?)
Дата
Msg-id 20191210180705.GA12733@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: Contention on LWLock buffer_content, due to SHARED lock(?)  (Andres Freund <andres@anarazel.de>)
Ответы Re: Contention on LWLock buffer_content, due to SHARED lock(?)  (Jens-Wolfhard Schicke-Uffmann <drahflow@gmx.de>)
Список pgsql-hackers
On 2019-Dec-10, Andres Freund wrote:

> >    The hard part would probably be to ensure that an
> >    attempt to obtain an EXCLUSIVE lock would finally succeed against a
> >    SHARE lock held by "everyone".
> 
> Note that this is a seriously complicated area of the code. It's very
> easy to create new bugs that aren't easily testable. I think we'd need a
> very convincing use-case for improvements around the problem you outline
> and relatively simple solution, to counter stability concerns.

I'd rather have the ability to mark a table READ ONLY (or similar).
Then any FK references can skip the row locks altogether.  For the rare
cases where you need to modify the referenced table, have it marked READ
WRITE, and any row locks are registered normally from that point on,
until you set it back to READ ONLY again.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: allowing broader use of simplehash
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: xact_start for walsender & logical decoding not updated