Re: Problem with PostgreSQL 9.2.7 and make check on AIX 7.1

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Rainer Tammer <pgsql(at)spg(dot)schulergroup(dot)com>
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:26:31
Message-ID: 3853.1393352791@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Rainer Tammer 2014-02-25 18:43:53 Re: Problem with PostgreSQL 9.2.7 and make check on AIX 7.1
Previous Message Rainer Tammer 2014-02-25 17:58:49 Re: Problem with PostgreSQL 9.2.7 and make check on AIX 7.1