"Jeffrey W. Baker" <jwbaker@acm.org> writes:
> #0 semop (semid=1277952, sops=0xbfffe934, nsops=1) at
> ../sysdeps/unix/sysv/linux/semop.c:35
> #1 0x81504d2 in IpcSemaphoreUnlock (semId=1277952, sem=0) at ipc.c:456
> #2 0x8157fa6 in LWLockRelease (lockid=LockMgrLock) at lwlock.c:455
> #3 0x8154a5f in LockAcquire (lockmethod=1, locktag=0xbfffea50,
> xid=6753879, lockmode=1, dontWait=0 '\000')
> at lock.c:723
> #4 0x81537fb in LockRelation (relation=0x4054a070, lockmode=1) at
> lmgr.c:153
> and :
> #0 semop (semid=1277952, sops=0xbfffe9b0, nsops=1) at
> ../sysdeps/unix/sysv/linux/semop.c:35
> #1 0x8150424 in IpcSemaphoreLock (semId=1277952, sem=2, interruptOK=0
> '\000') at ipc.c:422
> #2 0x8157bfb in LWLockAcquire (lockid=LockMgrLock, mode=LW_EXCLUSIVE) at
> lwlock.c:271
> #3 0x8154fb2 in LockRelease (lockmethod=1, locktag=0xbfffea80,
> xid=6753879, lockmode=1) at lock.c:1018
> #4 0x81539f9 in UnlockRelation (relation=0x4054b8f8, lockmode=1) at
> lmgr.c:217
Hmm, those look perfectly normal, except one would like to think it's
the exception not the rule to be blocking on LWLocks. If you're seeing
a lot of semops coming from these code paths then something unhappy is
going on (and I would imagine that 7.1 would've been worse, since it
would busy-wait under similar conditions).
Could we get some details about your application? How many active
backends do you have, and what are they doing? A query trace
(postmaster log with debug_print_query on) might be helpful.
regards, tom lane