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().


Andres Freund

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to