Craig Vosburgh <craig.vosburgh@xxxxxxxxxxx> writes: > Got GDB installed on the errant node and did a back trace call (I'm guessing > that is what you were looking for when you said stack trace) on the process > that shows in the process table as executing the hung SQL command. > The backtrace is: > (gdb) bt > #0 0x0088b7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0x0096f3ab in semop () from /lib/tls/libc.so.6 > #2 0x081ba8f8 in PGSemaphoreLock () > #3 0x081e4d9e in ProcSleep () > #4 0x081e1db3 in GrantAwaitedLock () > #5 0x0832f984 in twophase_recover_callbacks () > #6 0x00000006 in ?? () Hmm. gdb is lying to you, because GrantAwaitedLock doesn't call ProcSleep --- probably line 4 should refer to WaitOnLock instead. You could try installing a non-symbol-stripped postgres executable (or in RPM environments, install the matching debuginfo RPM) to get a more trustworthy backtrace. However, what I suspect you are looking at is just a run-of-the-mill lock wait. You *sure* there's no ungranted locks showing in pg_locks? regards, tom lane
