Re: Atomic ops for unlogged LSN - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: Atomic ops for unlogged LSN
Date
Msg-id 20231109212733.GA1219183@nathanxps13
Whole thread Raw
In response to Re: Atomic ops for unlogged LSN  (Andres Freund <andres@anarazel.de>)
Responses Re: Atomic ops for unlogged LSN
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pg_walfile_name_offset can return inconsistent values
Next
From: Michael Paquier
Date:
Subject: Re: speed up a logical replica setup