On 12/6/21 01:02, Tom Lane wrote: > Andrew Dunstan <and...@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
