Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1nbRx8-00009n-By
	for pgsql-hackers@arkaria.postgresql.org; Mon, 04 Apr 2022 19:01:26 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.92)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1nbRx7-00037l-7F
	for pgsql-hackers@arkaria.postgresql.org; Mon, 04 Apr 2022 19:01:25 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
	by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1nbRx6-00037b-UK
	for pgsql-hackers@lists.postgresql.org; Mon, 04 Apr 2022 19:01:24 +0000
Received: from sss.pgh.pa.us ([66.207.139.130])
	by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1nbRx4-0000pc-4B
	for pgsql-hackers@postgresql.org; Mon, 04 Apr 2022 19:01:24 +0000
Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 234J1FdE1974786;
	Mon, 4 Apr 2022 15:01:15 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Mark Dilger <mark.dilger@enterprisedb.com>
cc: Thomas Munro <thomas.munro@gmail.com>,
        PostgreSQL-development <pgsql-hackers@postgresql.org>,
        Joshua Brindle <joshua.brindle@crunchydata.com>,
        Robert Haas <robertmhaas@gmail.com>,
        Andrew Dunstan <andrew@dunslane.net>, Jeff Davis <pgsql@j-davis.com>,
        Joe Conway <joe@crunchydata.com>
Subject: Re: New Object Access Type hooks
In-reply-to: <2BD8BDA8-A963-4D64-8B69-8F7EDF9AEA2D@enterprisedb.com>
References: <47F87A0E-C0E5-43A6-89F6-D403F2B45175@enterprisedb.com> <CA+hUKG+LOza8iSLiv6ymn=0R8S0x-R7KaqZmYfY+_b_cubcDOg@mail.gmail.com> <17BD82D7-49AC-40C9-8204-E7ADD30321A0@enterprisedb.com> <1918971.1649091790@sss.pgh.pa.us> <1922986.1649094077@sss.pgh.pa.us> <1923706.1649094673@sss.pgh.pa.us> <AACAF464-092B-4497-ADA2-AE1B122FAC6A@enterprisedb.com> <1925660.1649095626@sss.pgh.pa.us> <2BD8BDA8-A963-4D64-8B69-8F7EDF9AEA2D@enterprisedb.com>
Comments: In-reply-to Mark Dilger <mark.dilger@enterprisedb.com>
	message dated "Mon, 04 Apr 2022 11:09:45 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1974784.1649098875.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 04 Apr 2022 15:01:15 -0400
Message-ID: <1974785.1649098875@sss.pgh.pa.us>
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Archived-At: <https://www.postgresql.org/message-id/1974785.1649098875%40sss.pgh.pa.us>
Precedence: bulk

Mark Dilger <mark.dilger@enterprisedb.com> writes:

> # Running: pg_ctl kill QUIT 2083
> ok 4 - killed process with SIGQUIT
> # pump_until: process terminated unexpectedly when searching for "(?^m:W=
ARNING:  terminating connection because of crash of another server process=
|server closed the connection unexpectedly|connection to server was lost)"=
 with stream: "psql:<stdin>:9: WARNING:  terminating connection because of=
 unexpected SIGQUIT signal
> # psql:<stdin>:9: could not send data to server: Socket is not connected
> # "
> not ok 5 - psql query died successfully after SIGQUIT

And there we have it: the test wasn't updated for the new backend message
spelling, and we're seeing a different frontend behavior.  Evidently the
backend is dying before we're able to send the "SELECT 1;" to it.

I'm not quite sure whether it's a libpq bug that it doesn't produce the
"connection to server was lost" message here, but in any case I suspect
that we shouldn't be checking for the second and third regex alternatives.
The "terminating connection" warning absolutely should get through, and
if it doesn't we want to know about it.  So my proposal for a fix is
to change the regex to be just "WARNING:  terminating connection because
of unexpected SIGQUIT signal".

			regards, tom lane