"Meetesh Karia" <meetesh.karia@gmail.com> writes:
> ... But, once again we ran into the same
> situation where a query that normally executes in ~15ms wouldn't finish. As
> before, there were no ungranted locks and threads weren't waiting on a
> lock. I attached gdb to one of the stuck postgres processes and got the
> following stack trace:
> #0 0x008967a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
> #1 0x00977e5b in semop () from /lib/tls/libc.so.6
> #2 0x08167298 in PGSemaphoreLock ()
> #3 0x0818bcb5 in LWLockAcquire ()
> #4 0x080a47f5 in SimpleLruWritePage ()
> #5 0x080a48ad in SimpleLruReadPage ()
> #6 0x080a519a in SubTransGetParent ()
> #7 0x080a51f2 in SubTransGetTopmostTransaction ()
> #8 0x0821371c in HeapTupleSatisfiesSnapshot ()
What I'm wondering about is possible deadlock conditions inside slru.c.
There's no deadlock detection for LWLocks, so if it happened, the
processes involved would just freeze up.
If this happens again, would you collect stack traces from all the stuck
processes, not just one?
regards, tom lane