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
