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