Re: Rare SSL failures on eelpout
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2019-03-17T22:41:41Z
Lists: pgsql-hackers
Thomas Munro <thomas.munro@gmail.com> writes: > On Sun, Mar 17, 2019 at 2:00 AM Thomas Munro <thomas.munro@gmail.com> wrote: >> I opened a bug report with OpenSSL, let's see what they say: >> https://github.com/openssl/openssl/issues/8500 > This was an intentional change in TLS1.3, reducing round trips by > verifying the client certificate later. Ugh. So probably we can reproduce it elsewhere if we use cutting-edge OpenSSL versions. > I'm pretty sure the fix I mentioned earlier -- namely adding an ad-hoc > call to pqHandleSendFailure() if we fail to send the start-up packet > -- would fix eelpout's measles (though obviously wouldn't solve the > problem for Windows given what we have learned about its TCP > implementation). I should probably go and do that, unless you want to > write the more general handling for send failure you described, and > are prepared to back-patch it? Well, I'm not sure about the back-patching aspect of that, but maybe I should write the patch and then we should see how risky it looks. Give me a few days ... regards, tom lane
Commits
-
Hack back-branch SSL tests to avoid intermittent buildfarm failures.
- 08cf04bb4747 11.3 landed
-
Restructure libpq's handling of send failures.
- 1f39a1c06415 12.0 landed