Re: 9.1.11 - many backends in "semtimedop" syscall
От | hubert depesz lubaczewski |
---|---|
Тема | Re: 9.1.11 - many backends in "semtimedop" syscall |
Дата | |
Msg-id | 20140306165752.GA4858@depesz.com обсуждение исходный текст |
Ответ на | Re: 9.1.11 - many backends in "semtimedop" syscall (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: 9.1.11 - many backends in "semtimedop" syscall
|
Список | pgsql-general |
On Thu, Mar 06, 2014 at 11:56:06AM -0500, Tom Lane wrote: > 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. I didn't have a chance to do it. Can try if there is a way to get trace *without* making core (sorry, my c/gdb knowledge is very, very limited). Best regards, depesz -- The best thing about modern society is how easy it is to avoid contact with it. http://depesz.com/
Вложения
В списке pgsql-general по дате отправления: