"Eric B. Ridge" <e...@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 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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
