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
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: