On Wed, May 27, 2015 at 6:55 PM, Andres Freund <and...@anarazel.de> wrote: > On 2015-05-27 15:39:14 -0400, Robert Haas wrote: >> On Mon, May 25, 2015 at 10:05 PM, Andres Freund <and...@anarazel.de> wrote: >> > Hm. So we have a *occasional* stack size exceeded failure and an >> > occasional spinlock error in test_shm_mq. I'm inclined to think that >> > this is a shm_mq problem, and not a more general locking problem - it >> > seems likely, but not guaranteed, that that'd have materialized >> > elsewhere. >> >> I think the problem might be that the spinlock-based memory barrier is >> not re-entrant. Suppose some kind of barrier operation is in process, >> and we've acquired the dummy spnlock but not yet released it. Just >> then, we receive a signal. Since the shm_mq code sets >> set_latch_on_sigusr1, procsignal_sigusr1_handler will set MyLatch. >> SetLatch now includes barrier operations, so we'll try to acquire and >> release the spinlock despite already holding it. Oops. > > Oh wow, that's bad, and could explain a couple of the problems we're > seing. One possible way to fix is to replace the sequence with if > (!TAS(spin)) S_UNLOCK();. But that'd mean TAS() has to be a barrier, > even if the lock isn't free - which e.g. isn't the case for PowerPC's > implementation :(
Another possibility is to make the fallback barrier implementation a system call, like maybe kill(PostmasterPid, 0). -- 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
