"Dan Armbrust" <daniel.armbrust.list@gmail.com> writes:
> I had to restart postgres to let things recover - so I can't gather
> any more info right now - but if/when it happens again, I'd like to
> know what else to gather.
Well, there went the evidence :-( ... but what exactly did you have
to do to shut it down? I'm wondering whether the backends responded
to SIGINT or SIGTERM.
Next time, it'd be good to confirm (with top or vmstat or similar)
whether the backends are actually idle or are eating CPU or I/O.
Also try strace'ing a few of them; the pattern of kernel calls if
any would be revealing.
The lack of deadlock reports or 't' values in pg_stat_activity.waiting
says that you weren't blocking on heavyweight locks. It's not
impossible that there was a deadlock at the LWLock level, though.
What sort of indexes are there on this table? Teodor just fixed
an issue in GIN indexes that involved taking an unreasonable number of
LWLocks, and if that code wasn't exposing itself to deadlock risks
I'd be pretty surprised.
regards, tom lane
