Re: BUG #17391: While using --with-ssl=openssl and PG_TEST_EXTRA='ssl' options, SSL tests fail on OpenBSD 7.0
От | Tom Lane |
---|---|
Тема | Re: BUG #17391: While using --with-ssl=openssl and PG_TEST_EXTRA='ssl' options, SSL tests fail on OpenBSD 7.0 |
Дата | |
Msg-id | 2077573.1644599439@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #17391: While using --with-ssl=openssl and PG_TEST_EXTRA='ssl' options, SSL tests fail on OpenBSD 7.0 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #17391: While using --with-ssl=openssl and PG_TEST_EXTRA='ssl' options, SSL tests fail on OpenBSD 7.0
|
Список | pgsql-bugs |
I wrote: > Andres Freund <andres@anarazel.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
В списке pgsql-bugs по дате отправления: