From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Eric B(dot) Ridge" <ebr(at)tcdi(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org, Mike Weber <j_weber(at)tcdi(dot)com> |
Subject: | Re: Postgres "locked up" |
Date: | 2009-12-10 23:58:07 |
Message-ID: | 3333.1260489487@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Eric B. Ridge" <ebr(at)tcdi(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Windsor | 2009-12-11 00:06:47 | PIVOT tables and crosstab |
Previous Message | Tom Lane | 2009-12-10 23:42:32 | Re: Restore time differences between full database dumps and separate schema/data dumps |