On Sat, Jun 20, 2015 at 12:24 AM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Has anybody noticed the way castoroides is randomly failing? > > SELECT test_shm_mq_pipelined(16384, (select > string_agg(chr(32+(random()*95)::int), '') from generate_series(1,270000)), > 200, 3); > ! PANIC: stuck spinlock (100cb92f4) detected at atomics.c:30 > ! server closed the connection unexpectedly > ! This probably means the server terminated abnormally > ! before or while processing the request. > ! connection to server was lost
Yeah, Andres and I discussed it a month ago: http://www.postgresql.org/message-id/20150527225528.gp5...@alap3.anarazel.de I think we're going to need to try to implement real memory barriers on all architectures we support. It's not clear whether there's some suitable generic fallback that we could use or whether we're going to need something different for each case. I had thought Andres was planning to work on this. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
