Re: Hung SQL Update Linux Redhat 4U5 Postgres 8.3.1

Craig Vosburgh <craig(dot)vosburgh(at)cassatt(dot)com> 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