On 2019-02-19 18:02, Andres Freund wrote: > Because SetLatch() is careful to have a pg_memory_barrier() before > touching shared state and conversely so are ResetLatch() (and > WaitEventSetWait(), which already has no volatiles). And if we've got > this wrong they aren't safe for shared latches, because volatiles don't > enforce meaningful ordering on weakly ordered architectures.
That makes sense. > But even if we were to decide we'd want to keep a volatile in SetLatch() > - which I think really would only serve to hide bugs - that'd not mean > it's a good idea to keep it on all the other functions in latch.c. What is even the meaning of having a volatile Latch * argument on a function when the actual latch variable (MyLatch) isn't volatile? That would just enforce certain constraints on the compiler inside that function but not on the overall program, right? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
