|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>|
|Cc:||Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Joshua Brindle <joshua(dot)brindle(at)crunchydata(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Jeff Davis <pgsql(at)j-davis(dot)com>, Joe Conway <joe(at)crunchydata(dot)com>|
|Subject:||Re: New Object Access Type hooks|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> writes:
> I just got a crash in this test again. Are you still interested? I still have the logs. No core file appears to have been generated.
> The test failure is
> not ok 5 - psql query died successfully after SIGQUIT
Hmm ... I can see one problem with that test:
qr/WARNING: terminating connection because of crash of another server process|server closed the connection unexpectedly|connection to server was lost/m
"psql query died successfully after SIGQUIT");
It's been a little while since that message looked like that.
Nowadays you get
WARNING: terminating connection because of unexpected SIGQUIT signal
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
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.
regards, tom lane
|Next Message||David Steele||2022-04-04 17:11:33||Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file|
|Previous Message||Tom Lane||2022-04-04 16:39:59||Re: A test for replay of regression tests|