On 2016-10-05 15:02:09 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > Without yet having analyzed this deeply, could it actually be that the
> > reason is that sem_post/wait aren't proper memory barriers? On a glance
> > the symptoms look like values have been modified without proper locks...
>
> Hmm, possible ...
Hm. After a long battle of head vs. wall I think I see what the problem
is. For the fallback atomics implementation I somehow had assumed that
pg_atomic_write_u32() doesn't need to lock, as it's just an unlocked
write. But that's not true, because it has to cause
pg_atomic_compare_exchange_u32 to fail. The lack of this can cause a
"leftover" lockbit, when UnlockBufHdr() occurs concurrently an operation
using compare_exchange.
For me the problem often takes a lot longer to reproduce (once only
after 40min), could you run with the attached patch, and see whether
that fixes things for you?
Andres
