On Sun, Jun 28, 2015 at 9:17 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> That sucks. It was easy to see that the old fallback barrier >> implementation wasn't re-entrant, but this one should be. And now >> that I look at it again, doesn't the failure message indicate that's >> not the problem anyway? > >> ! PANIC: stuck spinlock (c00000000d6f4140) detected at lwlock.c:816 >> ! PANIC: stuck spinlock (c00000000d72f6e0) detected at lwlock.c:770 > > I was assuming that a leaky memory barrier was allowing the spinlock > state to become inconsistent, or at least to be perceived as inconsistent. > But I'm not too clear on how the barrier changes you and Andres have been > making have affected the spinlock code.
For the most part, they haven't. Andres did a bunch of work to add atomics support, and overhauled the barrier implementation that I committed to 9.2 along the way. But that had minimal impact on s_lock.h. What we did do that touched s_lock.h was attempt to ensure that SpinLockAcquire() and SpinLockRelease() function as compiler barriers, so that it should no longer be necessary to litter the code with "volatile" in every function that uses those. It is possible that this could be broken on HP-UX. If _Asm_sched_fence() doesn't constraint the compiler appropriately, that could explain the problems we're seeing here. But we're not the only one using that incantation, so I'm left scratching my head. -- 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
