Re: castoroides spinlock failure on test_shm_mq
От | Robert Haas |
---|---|
Тема | Re: castoroides spinlock failure on test_shm_mq |
Дата | |
Msg-id | CA+TgmoYCW9puxKosH1fHgOUejGMiGRSzSZJLsc1fOJ+-Hc4Pig@mail.gmail.com обсуждение исходный текст |
Ответ на | castoroides spinlock failure on test_shm_mq (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: castoroides spinlock failure on test_shm_mq
|
Список | pgsql-hackers |
On Sat, Jun 20, 2015 at 12:24 AM, Alvaro Herrera <alvherre@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.GP5310@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
В списке pgsql-hackers по дате отправления: