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

Hello,
OK, so SIGALRM will kill the worker process if the timer runs down.


 tammer  7078048 10289298   0 18:43:45  pts/1  0:00 gmake -C
src/test/regress check
 tammer  9175106 12386340   0 18:45:31  pts/1  0:00
/daten/source/postgresql-9.2.7/src/test/regress/./tmp_check/install//usr/local/pgsql-9.2.7/bin/psql
-X -a -q -d regression
 tammer 10289298 20512896   0 18:43:39  pts/1  0:00 gmake check
 tammer 12189838 20840526   0 18:44:37      -  0:00 postgres: autovacuum
launcher process
 tammer 12386340  7078048   0 18:43:45  pts/1  0:00
../../../src/test/regress/pg_regress --inputdir=.
--temp-install=./tmp_check --top-builddir=../../.. --dlpath=.
--schedule=./parallel_schedule
 tammer 13172918 20840526   0 18:44:37      -  0:00 postgres: wal writer
process
 tammer 16777336 20840526   0 18:44:37      -  0:00 postgres:
checkpointer process
 tammer 18874572 20840526   0 18:45:31      -  0:00 postgres: tammer
regression [local] SELECT waiting  <------ here
 tammer 20512896 15270014   0 18:36:19  pts/1  0:00 -ksh
 tammer 20644046 20840526   0 18:44:37      -  0:00 postgres: writer process
 tammer 20840526 12386340   0 18:44:37  pts/1  0:00
/daten/source/postgresql-9.2.7/src/test/regress/./tmp_check/install//usr/local/pgsql-9.2.7/bin/postgres
-D /daten/source/postgresql-9.2.7/src/test/regress/./tmp_check/data -F
-c listen_addresses=
 tammer 24182972 20840526   0 18:44:37      -  0:00 postgres: stats
collector process

The worker is hanging here:

root@adsmsrv4 rc:0 # dbx -a 18874572
Waiting to attach to process 18874572 ...
Successfully attached to postgres.
warning: Directory containing postgres could not be determined.
Apply 'use' command to initialize source path.

Type 'help' for help.
reading symbolic information ...
stopped in semop at 0xd02f8df0 ($t1)
0xd02f8df0 (semop+0xb0) 80410014            lwz   r2,0x14(r1)
(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
relation_openrv_extended(0x2020f5d8, 0x1, 0x1000001) at 0x1004e76c
heap_openrv_extended(0x2020f5d8, 0x1, 0x1000001) at 0x1004eb98
parserOpenTable(0x2020f6d8, 0x2020f5d8, 0x1) at 0x101abeb0
addRangeTableEntry(0x2020f6d8, 0x2020f5d8, 0x0, 0x1000001, 0x1000001) at
0x101ac534
transformTableEntry(0x2020f6d8, 0x2020f5d8) at 0x1027f42c
transformFromClauseItem(0x2020f6d8, 0x2020f5d8, 0x2ff1e05c, 0x2ff1e060,
0x2ff1e064, 0x2ff1e068) at 0x1027f528
transformFromClause(0x2020f6d8, 0x2020f610) at 0x102800c8
transformSelectStmt(0x2020f6d8, 0x2020f628) at 0x10313f90
transformStmt(0x2020f6d8, 0x2020f628) at 0x1031559c
transformTopLevelStmt(0x2020f6d8, 0x2020f628) at 0x10315788
parse_analyze(0x2020f628, 0x2020ec10, 0x0, 0x0) at 0x1031583c
pg_analyze_and_rewrite(0x2020f628, 0x2020ec10, 0x0, 0x0) at 0x10062528
exec_simple_query(0x2020ec10) at 0x10066b74
PostgresMain(0x1, 0x201f6048, 0x201f5ed8, 0x201f5ec8) at 0x10067e4c
BackendRun(0x20234ad8) at 0x10117e54
BackendStartup(0x20234ad8) at 0x10119618
ServerLoop() at 0x10119c08
PostmasterMain(0x6, 0x201f56c8) at 0x1011b65c
main(0x6, 0x201f56c8) at 0x10000b1c

So the SELECT is waiting for the lock. The SIGALRM should send a SININT
to this worker process to terminate the worker.



Bye
  Rainer

On 25.02.2014 18:18, Tom Lane wrote:
> Rainer Tammer <pgsql@spg.schulergroup.com> writes:
>> What code path is executed if the timeout passes and
>> the signal is send?
> Well, the general idea (pre 9.3) is that at the start of the statement,
> enable_sig_alarm calculates a future timeout instant and calls setitimer()
> to schedule a SIGALRM signal then.  When the signal is delivered,
> CheckStatementTimeout should do kill(MyProcPid, SIGINT), which should
> lead to ProcessInterrupts calling ereport(ERROR), which will longjmp
> back to the process idle loop.  We need to narrow down which of these
> steps is failing to happen before we can speculate much on what's wrong.
>
> There are scenarios in which the SIGINT handler proper won't think it's
> safe to call ProcessInterrupts immediately, but will just set a flag
> to make that happen later.  That should not apply in these test cases,
> though.
>
>             regards, tom lane
>
>