Re: Hung SQL Update Linux Redhat 4U5 Postgres 8.3.1

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