Hi, On 2020-06-14 22:30:25 -0400, Tom Lane wrote: > Noah Misch <n...@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
