Re: Hung SQL Update Linux Redhat 4U5 Postgres 8.3.1 - Mailing list pgsql-general

From Tom Lane
Subject Re: Hung SQL Update Linux Redhat 4U5 Postgres 8.3.1
Date
Msg-id 23465.1210616166@sss.pgh.pa.us
Whole thread Raw
In response to Re: Hung SQL Update Linux Redhat 4U5 Postgres 8.3.1  (Craig Vosburgh <craig.vosburgh@cassatt.com>)
Responses Re: Hung SQL Update Linux Redhat 4U5 Postgres 8.3.1  (Craig Vosburgh <craig.vosburgh@cassatt.com>)
List pgsql-general
Craig Vosburgh <craig.vosburgh@cassatt.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

pgsql-general by date:

Previous
From: Lincoln Yeoh
Date:
Subject: Re: rounding problems
Next
From: Andy Anderson
Date:
Subject: Re: rounding problems