On 2016-04-11 23:41:10 -0400, Tom Lane wrote:
> Andres Freund <andres@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().
>
> The stack trace I'm seeing is
>
> #5 0x7279cc in elog_finish (elevel=6,
> fmt=0x40057cf8 '\177' <repeats 200 times>...) at elog.c:1378
> #6 0x5cecd8 in s_lock_stuck (p=0x402995b8, file=0x21bae0 "s_lock.c", line=92)
> at s_lock.c:81
> #7 0x5cedd4 in perform_spin_delay (status=0x7b03b8c8) at s_lock.c:130
> #8 0x5ced40 in s_lock (lock=0x6, file=0x20 <Address 0x20 out of bounds>,
> line=6) at s_lock.c:96
> #9 0x53a4b0 in pg_atomic_compare_exchange_u32_impl (ptr=0x402995b8,
> expected=0x5c, newval=58982400) at atomics.c:122
> #10 0x5a280c in MarkLocalBufferDirty (buffer=6)
> at ../../../../src/include/port/atomics/generic.h:224
Ok, so the theory above fits.
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.
Thanks,
Andres