Re: New Object Access Type hooks

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
Date: 2022-04-04 17:03:10
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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:

ok( pump_until(
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

In response to


Browse pgsql-hackers by date

  From Date Subject
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