From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: Daniel Gustafsson <daniel@yesql.se>,
 Thomas Munro <thomas.munro@gmail.com>,
        byavuz81@gmail.com,
        PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>,
        Heikki Linnakangas <heikki.linnakangas@iki.fi>,
        Michael Paquier <michael@paquier.xyz>
Subject: Re: BUG #17391: While using --with-ssl=openssl and
 PG_TEST_EXTRA='ssl' options, SSL tests fail on OpenBSD 7.0
In-reply-to: <1959196.1644544971@sss.pgh.pa.us>
References: <C44CE9FB-B37E-47D3-924B-4AF808AE98B1@yesql.se>
 <887CBA28-0942-4084-BE09-FBE0D6A1DB53@yesql.se>
 <621771.1644098845@sss.pgh.pa.us> <635760.1644108785@sss.pgh.pa.us>
 <1113966.1644280235@sss.pgh.pa.us>
 <C112C400-2CB5-4DCA-A699-00DC0333B665@yesql.se>
 <1537890.1644462214@sss.pgh.pa.us> <1952254.1644540297@sss.pgh.pa.us>
 <20220211011025.ek7exh6owpzjyudn@alap3.anarazel.de>
 <1955929.1644542728@sss.pgh.pa.us>
 <20220211015455.mkl6cvstttp5zfco@alap3.anarazel.de>
 <1959196.1644544971@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Thu, 10 Feb 2022 21:02:51 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2077572.1644599439.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 11 Feb 2022 12:10:39 -0500
Message-ID: <2077573.1644599439@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2077573.1644599439%40sss.pgh.pa.us>
Precedence: bulk

I wrote:
> Andres Freund <andres@anarazel.de> writes:
>> I wonder if it could be part of the whole "walreceiver on windows not n=
oticing
>> connection death" business.

> Hmm, maybe.  It sure *looks* like we need to do

> -	return conn->asyncStatus =3D=3D PGASYNC_BUSY || conn->write_failed;
> +	return conn->asyncStatus =3D=3D PGASYNC_BUSY && !conn->write_failed;

Dunno anything about the Windows angle, but after hacking together
a reproducer for this, I'm fairly convinced that this is indeed a bug.
The reasons we've not heard complaints are:

1. It's hard to get to.  Normally, if we hit a connection-close error
while writing, we'll come back to pqSendSome which will try to read
some data and will notice the closed connection from the read side,
thus immediately reporting an error.  Thus, usually the application
will see a failure from PQsendQuery and will never get to PQisBusy.

2. If you do manage to get into the state where PQisBusy falsely
returns true, the app is supposed to call PQconsumeInput, which
will definitely notice the closed connection from the read side
and report failure.  So there won't be anything as obvious as
an infinite loop --- but people probably don't realize that that's
not the way it's supposed to go.  You're supposed to be able to
get a PGresult from this situation, but you don't.

			regards, tom lane