On 2016-04-11 23:59:21 -0400, Tom Lane wrote:
> Andres Freund writes:
> > 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.
Well, it
Andres Freund 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 ;-)
> Wi
On 2016-04-11 23:41:10 -0400, Tom Lane wrote:
> Andres Freund 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
>
>
Andres Freund 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
On 2016-04-11 23:24:36 -0400, Tom Lane wrote:
> Andres Freund 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 local
