From: | Rainer Tammer <pgsql(at)spg(dot)schulergroup(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs(at)postgresql(dot)org, cbbrowne(at)gmail(dot)com |
Subject: | Re: Problem with PostgreSQL 9.2.7 and make check on AIX 7.1 |
Date: | 2014-02-25 18:43:53 |
Message-ID: | 530CE469.2080902@spg.schulergroup.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)spg(dot)schulergroup(dot)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
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-02-25 18:47:03 | Re: Problem with PostgreSQL 9.2.7 and make check on AIX 7.1 |
Previous Message | Tom Lane | 2014-02-25 18:26:31 | Re: Problem with PostgreSQL 9.2.7 and make check on AIX 7.1 |