Re: 9.1.11 - many backends in "semtimedop" syscall - Mailing list pgsql-general

From Tom Lane
Subject Re: 9.1.11 - many backends in "semtimedop" syscall
Date
Msg-id 27155.1394124966@sss.pgh.pa.us
Whole thread Raw
In response to 9.1.11 - many backends in "semtimedop" syscall  (hubert depesz lubaczewski <depesz@depesz.com>)
Responses Re: 9.1.11 - many backends in "semtimedop" syscall  (hubert depesz lubaczewski <depesz@depesz.com>)
List pgsql-general
hubert depesz lubaczewski <depesz@depesz.com> writes:
> Thread 1 (LWP 21422):
> #0  0x00007ffa60da2dc7 in semop () from /lib/x86_64-linux-gnu/libc.so.6
> No symbol table info available.
> #1  0x00000000005f65e8 in PGSemaphoreLock ()
> No symbol table info available.
> #2  0x0000000000636125 in LWLockAcquire ()
> No symbol table info available.
> #3  0x0000000000630f91 in LockAcquireExtended ()
> No symbol table info available.
> #4  0x000000000062f88c in LockRelationOid ()
> No symbol table info available.
> #5  0x0000000000470f6d in relation_open ()
> No symbol table info available.

Huh.  Looks like it's blocked trying to acquire one of the lock-partition
LWLocks, which is odd because those ought never be held very long.
Somebody else has failed to release that LWLock, looks like.

Did you by any chance capture stack traces from all of the backends?
The interesting one would be the one that *doesn't* look like this.
Or possibly there's more than one such.

            regards, tom lane


pgsql-general by date:

Previous
From: Catherine Devlin
Date:
Subject: extract psql meta-commands into library?
Next
From: hubert depesz lubaczewski
Date:
Subject: Re: 9.1.11 - many backends in "semtimedop" syscall