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>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Thomas Munro <thomas.munro@gmail.com>, Andres Freund <andres@anarazel.de>,
byavuz81@gmail.com,
PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>,
Heikki Linnakangas <heikki.linnakangas@iki.fi>,
Michael Paquier <michael@paquier.xyz>
Date: 2022-02-10T03:03:34Z
Lists: pgsql-bugs
Daniel Gustafsson <daniel@yesql.se> writes: > On 8 Feb 2022, at 01:30, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> ..could we get away with ignoring EPIPE/ECONNRESET in writes during connection >> startup? We'd notice the failure soon enough on the read side if it's not this >> problem. (This seems a bit related to libpq's other hacks that postpone >> recognition of write failures.) > Off the cuff I can't think of a case where it would lead to adverse effects > *during startup*. Just to note that I have a plan for fixing this part. I've concluded that it was a design error to implement the write_failed error postponement mechanism in pqSendSome, and instead we should shove it down a couple of abstraction layers into pqsecure_raw_write. This'd visibly have no effect on non-encrypted connections, because pqSendSome is the only caller of pqsecure_write. But in encrypted connections, we'd be additionally allowing write-failure postponement during OpenSSL's internal machinations, which seems to be exactly what's wanted now that we have seen this failure mode. There are some details to work through, but I hope to have a patch soon. regards, tom lane
Commits
-
Move libpq's write_failed mechanism down to pqsecure_raw_write().
- faa189c932d5 15.0 landed
-
Fix thinko in PQisBusy().
- c9d35dc7f8a9 12.11 landed
- ae27b1acc43d 14.3 landed
- 51ee561f5671 13.7 landed
- 335fa5a26029 15.0 landed
-
Set SNI ClientHello extension to localhost in tests
- 6d503d2a4732 15.0 landed
- 5f00ef065ec8 14.3 landed
-
Improve worst-case performance of text_position_get_match_pos()
- b31e3f561365 15.0 cited