Rainer Tammer <pgsql@spg.schulergroup.com> writes:
> The worker is hanging here:
> (dbx) where
> semop(??, ??, ??) at 0xd02f8df0
> PGSemaphoreLock(0x32438750, 0x1000001) at 0x10060958
> ProcSleep(0x20212d18, 0x20039140) at 0x10114ab8
> WaitOnLock(0x20212d18, 0x201f74f0) at 0x101269c0
> LockAcquireExtended(0x2ff1dc90, 0x1, 0x0, 0x0, 0x1000001) at 0x10128384
> LockAcquire(0x2ff1dc90, 0x1, 0x0, 0x0) at 0x101284a0
> LockRelationOid(0xa35c, 0x1) at 0x10173d50
> RangeVarGetRelidExtended(0x2020f5d8, 0x1, 0x1000001, 0x0, 0x0, 0x0) at
> 0x1009dcf8
Pretty much as expected. So the question is why the signal isn't getting
serviced; semop() should be interruptable. Given that you found it works
again on a more recent AIX release, maybe that's an OS bug?
It'd be worth adding some elog printouts to try to confirm whether the
signal handlers are getting entered at all. It seems possible that the
SIGALRM handler is entered but then the nested SIGINT occurrence is
not serviced for some reason.
regards, tom lane