I looked at the postmaster log for the ongoing issue on narwhal
(to wit, that the contrib/dblink test dies the moment it tries
to do anything dblink-y), and looky here what the postmaster
has logged:
530fc965.bac:2] LOG: server process (PID 2144) exited with exit code 128
[530fc965.bac:3] DETAIL: Failed process was running: SELECT *
FROM dblink('dbname=contrib_regression','SELECT * FROM foo') AS t(a
int, b text, c text[])
WHERE t.a > 7;
[530fc965.bac:4] LOG: server process (PID 2144) exited with exit code 0
[530fc965.bac:5] LOG: terminating any other active server processes
The double report of the same process exiting can be attributed to
the kluge at postmaster.c lines 2906..2926 (in HEAD): that code
logs an ERROR_WAIT_NO_CHILDREN (128) exit and then resets the exitstatus
to zero. Further down, where we realize the process failed to disable
its deadman switch, we report the phony "exit 0" status and begin the
system reset cycle.
Now, back in the 2010 thread where we agreed to put in the ignore-128
kluge, it was asserted that all known cases of this exit code were
irreproducible Windows flakiness occurring at process start or exit.
This is evidently neither start nor exit, but likely is being provoked
by trying to load libpq into the backend. And it appears to be 100.00%
reproducible on narwhal.
Seems worth poking into a little closer. Not by me, though; I don't
do Windows.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
