Andres Freund <and...@anarazel.de> writes: >>> The issue is likely that either Alexander or I somehow made >>> MarkLocalBufferDirty() use pg_atomic_fetch_or_u32(), instead of the >>> proper pg_atomic_read_u32()/pg_atomic_write_u32().
> Ok, so the theory above fits. Yah, especially in view of localbuf.c:297 ;-) > Will fix (both initialization and use of pg_atomic_fetch_or_u32), and > expand the documentation on why only atomic read/write are supposed to > be used. FWIW, I'd vote against adding a SpinLockInit there. What it would mostly do is prevent noticing future mistakes of the same ilk. It would be better no doubt if we didn't have to rely on a nearly-dead platform to detect this; but having such detection of a performance bug is better than having no detection. regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers