On 12/6/21 01:02, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> On 12/5/21 12:50, Tom Lane wrote:
>>> This looks quite a bit like the sort of failure that commit
>>> 6051857fc was meant to forestall. I wonder whether reverting
>>> that commit changes the results? You might also try inserting
>>> a shutdown() call, as we'd decided not to do [1].
>> Commenting out the closesocket() worked.
> Man, that's annoying. Apparently OpenSSL is doing something to
> screw up the shutdown sequence. According to [1], the graceful
> shutdown sequence will happen by default, but changing SO_LINGER
> or SO_DONTLINGER can get you into abortive shutdown anyway.
> Maybe they change one of those settings (why?)
>
> regards, tom lane
>
> [1] https://docs.microsoft.com/en-us/windows/win32/winsock/graceful-shutdown-linger-options-and-socket-closure-2
Yeah, quite annoying, especially because only some combinations of MSVC
runtime / openssl version seem to trigger the problem.
Adding a shutdown() before the closesocket() also fixes the issue.
<https://docs.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-shutdown>
says:
To assure that all data is sent and received on a connected socket
before it is closed, an application should use shutdown to close
connection before calling closesocket.
...
Note The shutdown function does not block regardless of the
SO_LINGER setting on the socket.
Since we're not expecting anything back from the client I don't think we
need any of the recv calls the recipes there suggest.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com