Re: BUG #17391: While using --with-ssl=openssl and PG_TEST_EXTRA='ssl' options, SSL tests fail on OpenBSD 7.0

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Daniel Gustafsson <daniel(at)yesql(dot)se>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, byavuz81(at)gmail(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>, Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)fi>, Michael Paquier <michael(at)paquier(dot)xyz>
Subject: Re: BUG #17391: While using --with-ssl=openssl and PG_TEST_EXTRA='ssl' options, SSL tests fail on OpenBSD 7.0
Date: 2022-02-11 17:10:39
Message-ID: 2077573.1644599439@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

I wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
>> I wonder if it could be part of the whole "walreceiver on windows not noticing
>> connection death" business.

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

> - return conn->asyncStatus == PGASYNC_BUSY || conn->write_failed;
> + return conn->asyncStatus == 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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2022-02-11 19:28:12 Re: ERROR: XX000: variable not found in subplan target list
Previous Message Ryan Kelly 2022-02-11 16:34:14 Re: ERROR: XX000: variable not found in subplan target list