Re: Atomic ops for unlogged LSN

Поиск
Список
Период
Сортировка
От Nathan Bossart
Тема Re: Atomic ops for unlogged LSN
Дата
Msg-id 20231109212733.GA1219183@nathanxps13
обсуждение исходный текст
Ответ на Re: Atomic ops for unlogged LSN  (Andres Freund <andres@anarazel.de>)
Ответы Re: Atomic ops for unlogged LSN  (Nathan Bossart <nathandbossart@gmail.com>)
Список pgsql-hackers
On Tue, Nov 07, 2023 at 04:58:16PM -0800, Andres Freund wrote:
> On 2023-11-07 11:02:49 -0600, Nathan Bossart wrote:
>> Is there something special about all other backends being shut down that
>> ensures this returns the most up-to-date value and not something from "some
>> point in the past" as the stated contract for this function seems to
>> suggest?
> 
> Practically yes - getting to the point of writing the shutdown checkpoint
> implies having gone through a bunch of code that implies memory barriers
> (spinlocks, lwlocks).

Sure.

> However, even if there's likely some other implied memory barrier that we
> could piggyback on, the patch much simpler to understand if it doesn't change
> coherency rules. There's no way the overhead could matter.

I wonder if it's worth providing a set of "locked read" functions.  Those
could just do a compare/exchange with 0 in the generic implementation.  For
patches like this one where the overhead really shouldn't matter, I'd
encourage folks to use those to make it easy to reason about correctness.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com



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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: pg_walfile_name_offset can return inconsistent values
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: speed up a logical replica setup