I wrote:
> Usually the test would succeed anyway because of matching the
> second or third regex alternative, but I wonder if there is
> some other spelling of libpq's complaint that shows up
> occasionally. It'd be nice if we could see the contents of
> $killme_stderr upon failure.
OK, now I'm confused, because pump_until is very clearly
*trying* to report exactly that:
if (not $proc->pumpable())
{
diag("pump_until: process terminated unexpectedly when searching
for \"$until\" with stream: \"$$stream\"");
return 0;
}
and if I intentionally break the regex then I do see this
output when running the test by hand:
# Running: pg_ctl kill QUIT 1922645
ok 4 - killed process with SIGQUIT
# pump_until: process terminated unexpectedly when searching for "(?^m:WARNING:
terminating connection because of crash of another server process|server
closed the connection foounexpectedly|connection to server was lost)" with
stream: "psql:<stdin>:9: WARNING: terminating connection because of unexpected
SIGQUIT signal
# psql:<stdin>:9: server closed the connection unexpectedly
# This probably means the server terminated abnormally
# before or while processing the request.
# "
not ok 5 - psql query died successfully after SIGQUIT
Is our CI setup failing to capture stderr from TAP tests??
regards, tom lane
