Re: Problem with PostgreSQL 9.2.7 and make check on AIX 7.1 - Mailing list pgsql-bugs

From Tom Lane
Subject Re: Problem with PostgreSQL 9.2.7 and make check on AIX 7.1
Date
Msg-id 3853.1393352791@sss.pgh.pa.us
Whole thread Raw
In response to Re: Problem with PostgreSQL 9.2.7 and make check on AIX 7.1  (Rainer Tammer <pgsql@spg.schulergroup.com>)
Responses Re: Problem with PostgreSQL 9.2.7 and make check on AIX 7.1
Re: Problem with PostgreSQL 9.2.7 and make check on AIX 7.1
List pgsql-bugs
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

pgsql-bugs by date:

Previous
From: Rainer Tammer
Date:
Subject: Re: Problem with PostgreSQL 9.2.7 and make check on AIX 7.1
Next
From: Rainer Tammer
Date:
Subject: Re: Problem with PostgreSQL 9.2.7 and make check on AIX 7.1