On 2016-04-11 23:24:36 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > Allow Pin/UnpinBuffer to operate in a lockfree manner. > > This commit has broken buildfarm member gaur, and no doubt pademelon > will be equally unhappy once it catches up to HEAD. The reason is that > you've caused localbuf.c to perform a whole bunch of atomic operations > on its buffer headers; and on machines that don't have native atomic > ops, there's a spinlock underlying those; and you did not bother to > ensure that appropriate SpinLockInit operations happen for local-buffer > headers. (HPPA, possibly alone among supported platforms, does not > think that SpinLockInit is equivalent to memset-to-zeroes.)
That's obviously borked, and need to be fixed. > While we could fix this by performing suitable SpinLockInit's on > local-buffer headers, I have to think that that's fundamentally the > wrong direction. The *entire* *point* of having local buffers is > that they are not subject to concurrency overhead. So IMO, sticking > atomic-ops calls into localbuf.c is broken on its face. Note that localbuf.c tries to be careful to only use pg_atomic_read_u32/pg_atomic_write_u32 - which don't have a concurrency overhead as they don't utilize atomic ops. 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(). Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
