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

  1. Move libpq's write_failed mechanism down to pqsecure_raw_write().

  2. Fix thinko in PQisBusy().

  3. Set SNI ClientHello extension to localhost in tests

  4. Improve worst-case performance of text_position_get_match_pos()