Craig Vosburgh <[EMAIL PROTECTED]> 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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
