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

From Rainer Tammer
Subject Re: Problem with PostgreSQL 9.2.7 and make check on AIX 7.1
Date
Msg-id 530CE469.2080902@spg.schulergroup.com
Whole thread Raw
In response to Re: Problem with PostgreSQL 9.2.7 and make check on AIX 7.1  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Problem with PostgreSQL 9.2.7 and make check on AIX 7.1
List pgsql-bugs
Hello,
one note.. it works in AIX 6.1 but not 7.1. So it could be a OS problem.
I have opened a support call at IBM. Maybe the have an idea.

The semop() should be interrupted by SIGINT, right?

Bye
  Rainer

On 25.02.2014 19:26, Tom Lane wrote:
> 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: Tom Lane
Date:
Subject: Re: Problem with PostgreSQL 9.2.7 and make check on AIX 7.1
Next
From: Tom Lane
Date:
Subject: Re: Problem with PostgreSQL 9.2.7 and make check on AIX 7.1