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-05T17:07:58Z
Lists: pgsql-hackers
Thomas Munro <thomas.munro@gmail.com> writes: > You can see that poll() already knew the other end had closed the > socket. Since this is clearly timing... let's see, yeah, I can make > it fail every time by adding sleep(1) before the comment "Send the > startup packet.". I assume that'll work on any Linux machine? Great idea, but no cigar --- doesn't do anything for me except make the ssl test really slow. (I tried it on RHEL6 and Fedora 28 and, just for luck, current macOS.) What this seems to prove is that the thing that's different about eelpout is the particular kernel it's running, and that that kernel has some weird timing behavior in this situation. I've also been experimenting with reducing libpq's SO_SNDBUF setting on the socket, with more or less the same idea of making the sending of the startup packet slower. No joy there either. Annoying. I'd be happier about writing code to fix this if I could reproduce it :-( regards, tom lane PS: but now I'm wondering about trying other non-Linux kernels.
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