"Eric B. Ridge" <ebr@xxxxxxxx> writes: > On Dec 10, 2009, at 6:28 PM, Tom Lane wrote: >> It looks like somehow the SInvalLock got stuck --- that would account >> for both the stack traces you show. > What's a SInvalLock? I looked at the code/comments for ReceiveSharedInvalidMessages(), but it didn't make much sense out of context. It's the lock that provides mutual exclusion for the shared-memory data structures belonging to the shared-cache-invalidation subsystem. Which doesn't help you much more than before. But both those stack traces looked like processes waiting to get access to sinval shared memory. >> I'm not sure though why a "reload" would appear to free things up. > Yeah, that's the most bizarre part. Damn near all the backends issued various commands, then froze again. "reload" seemed the quickest way, under pressure, to send all the backends some kind of signal. I didn't actually expect it to do anything, tho. sinval gets touched during startup of most every SQL command, so it's not too hard to credit that a locking problem there would result in behavior like that. I confess bafflement about the "reload" interaction though. It seems likely that the root cause is having somehow lost a wakeup signal somewhere, but I don't quite see how that would lead to this behavior. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
