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 1nbQio-00051H-UN
	for pgsql-hackers@arkaria.postgresql.org; Mon, 04 Apr 2022 17:42:34 +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 1nbQho-0007d8-KT
	for pgsql-hackers@arkaria.postgresql.org; Mon, 04 Apr 2022 17:41:32 +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 1nbQho-0007cz-Av
	for pgsql-hackers@lists.postgresql.org; Mon, 04 Apr 2022 17:41:32 +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 1nbQhg-0000De-LW
	for pgsql-hackers@postgresql.org; Mon, 04 Apr 2022 17:41:31 +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 234HfHdV1922987;
	Mon, 4 Apr 2022 13:41:18 -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: <1918971.1649091790@sss.pgh.pa.us>
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>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Mon, 04 Apr 2022 13:03:10 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1922985.1649094077.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 04 Apr 2022 13:41:17 -0400
Message-ID: <1922986.1649094077@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/1922986.1649094077%40sss.pgh.pa.us>
Precedence: bulk

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 searchi=
ng 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:WAR=
NING:  terminating connection because of crash of another server process|s=
erver closed the connection foounexpectedly|connection to server was lost)=
" with stream: "psql:<stdin>:9: WARNING:  terminating connection because o=
f 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