"Eric B. Ridge" <ebr@tcdi.com> 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
outof 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"
seemedthe quickest way, under pressure, to send all the backends some kind of signal. I didn't actually expect it to
doanything, 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
