Re: BufferAlloc: don't take two simultaneous locks

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: BufferAlloc: don't take two simultaneous locks
Дата
Msg-id CA+TgmoZkWfHpjSoA5e=BvTXvL4wtjW0yCWaMYNL2ExReG+7XeA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BufferAlloc: don't take two simultaneous locks  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Thu, Apr 14, 2022 at 11:27 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> If it's not atomic, then you have to worry about what happens if you
> fail partway through, or somebody else changes relevant state while
> you aren't holding the lock.  Maybe all those cases can be dealt with,
> but it will be significantly more fragile and more complicated (and
> therefore slower in isolation) than the current code.  Is the gain in
> potential concurrency worth it?  I didn't think so at the time, and
> the graphs upthread aren't doing much to convince me otherwise.

Those graphs show pretty big improvements. Maybe that's only because
what is being done is not actually safe, but it doesn't look like a
trivial effect.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Intermittent buildfarm failures on wrasse
Следующее
От: Robert Haas
Дата:
Сообщение: Re: make MaxBackends available in _PG_init