unexpected SIGALRM
От | Hiroshi Inoue |
---|---|
Тема | unexpected SIGALRM |
Дата | |
Msg-id | EKEJJICOHDIEMGPNIFIJCEHMGDAA.Inoue@tpf.co.jp обсуждение исходный текст |
Ответы |
Re: unexpected SIGALRM
|
Список | pgsql-hackers |
Hi all, I've examined a cygwin hangup issue for a pretty long time. It seems there are plural causes though it's hard for me to identify them all. Anyway I found some unexpected SIGALRM cases. It may be caused by a cygwin's bug but isn't it safer to return immediately from HandleDeadLock in any platform unless the backend is waiting for a lock ? The following is a back trace I saw very luckily. #0 0x77f827e8 in _libkernel32_a_iname () #1 0x77e56a15 in _libkernel32_a_iname () #2 0x77e56a3d in _libkernel32_a_iname () #3 0x00587535 in semop () #4 0x005086b0 in IpcSemaphoreLock (semId=2688, sem=1, interruptOK=0 '\000') at ipc.c:422 #5 0x005114f7 in LWLockAcquire (lockid=LockMgrLock, mode=LW_EXCLUSIVE) at lwlock.c:272 #6 0x005101ba in HandleDeadLock (postgres_signal_arg=14) at proc.c:862 #7 0x6100fb63 in _libkernel32_a_iname () #8 0x0058650d in do_semop () #9 0x00587535 in semop () #10 0x005086b0 in IpcSemaphoreLock (semId=2688, sem=1, interruptOK=0 '\000') at ipc.c:422 #11 0x005114f7 in LWLockAcquire (lockid=LockMgrLock, mode=LW_EXCLUSIVE) at lwlock.c:272 #12 0x0050e60b in LockRelease (lockmethod=1, locktag=0x22f338, xid=17826, lockmode=1) at lock.c:1018 #13 0x0050c8f5 in UnlockRelation (relation=0xa06c168, lockmode=1) at lmgr.c:217 #14 0x0041d29e in index_endscan (scan=0xa08a8f8) at indexam.c:288 #15 0x004ae558 in ExecCloseR (node=0xa089a88) at execAmi.c:232 #16 0x004b8de2 in ExecEndIndexScan (node=0xa089a88) at nodeIndexscan.c:474 #17 0x004b1e41 in ExecEndNode (node=0xa089a88, parent=0x0) at execProcnode.c:495 regards, Hiroshi Inoue
В списке pgsql-hackers по дате отправления: