Hi,
On 2020-06-14 22:30:25 -0400, Tom Lane wrote:
> Noah Misch <noah@leadboat.com> writes:
> > On Sun, Jun 07, 2020 at 12:23:35AM -0400, Tom Lane wrote:
> >> ... But on thinking more about this, it seems like
> >> generic.h's version of pg_atomic_init_u64_impl is just fundamentally
> >> misguided. Why isn't it simply assigning the value with an ordinary
> >> unlocked write? By definition, we had better not be using this function
> >> in any circumstance where there might be conflicting accesses
>
> > Does something guarantee the write will be globally-visible by the time the
> > first concurrent accessor shows up? (If not, one could (a) do an unlocked
> > ptr->value=0, then the atomic write, or (b) revert and improve the
> > suppression.) I don't doubt it's fine for the ways PostgreSQL uses atomics
> > today, which generally initialize an atomic before the concurrent-accessor
> > processes even exist.
>
> Perhaps it'd be worth putting a memory barrier at the end of the _init
> function(s)? As you say, this is hypothetical right now, but that'd be
> a cheap improvement.
I don't think it'd be that cheap for some cases. There's an atomic for
every shared buffer, making their initialization full memory barriers
would likely be noticable for larger shared_buffers values.
As you say:
> In practice, if that line is so fine that we need a memory sync operation
> to enforce it, things are probably broken anyhow.
Greetings,
Andres Freund