On 2016-10-06 00:06:33 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > 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. > > Hah ... obvious once you see it. > > > 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? > > For me, with the described test case, HEAD fails within a minute, > two times out of three or so. I've not reproduced it after half an > hour of beating on this patch. Looks good.
Advertising
It's not quite there yet, unfortunately. At the moment pg_atomic_write_u32() is used for local buffers - and we explicitly don't want that to be locking for temp buffers (c.f. 6b93fcd149329d4ee7319561b30fc15a573c6307). Don't really have a great idea about addressing this, besides either just living with the lock for temp buffers on fallback platforms (which don't have much of a practical relevance), or introduce pg_atomic_unlocked_write_u32() or something. Neither seems great. Regards, Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
