19.10.2020 22:18, Tom Lane wrote:
> Yeah, we've come to that conclusion before, see for instance
> https://www.postgresql.org/message-id/flat/E1iaD8h-0004us-K9%40gemulon.postgresql.org
>
> I haven't heard any non-unpleasant ideas for working around it.
>
> One thought that might or might not improve matters is for
> the backend to explicitly close() the socket before exiting.
> We intentionally don't do that (cf 268313a95), but maybe
> doing it on Windows would be better than the existing issue
> --- assuming it fixes the issue, that is.
Yes, close() fixes the issue for me, but I'm afraid that it maybe not
100% reliable (and Amit Kapila in [1] talked about it in the
aforementioned discussion).
Microsoft suggests using shutdown() to assure that all data is sent.
https://docs.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-shutdown
And the same is said in not so new, but may be still relevant article:
https://blog.netherlabs.nl/articles/2009/01/18/the-ultimate-so_linger-page-or-why-is-my-tcp-not-reliable
So I've also tested on Windows the following version:
secure_close(MyProcPort);
shutdown(MyProcPort->sock, SD_SEND);
for(;;) {
char buffer[1000];
int res = recv(MyProcPort->sock, buffer, 1000, 0);
if (res <= 0)
break;
}
closesocket(MyProcPort->sock);
And it works too. On my Ubuntu localhost I can't reproduce losing a
message (up to 1MB) on FATAL exit, so probably in 2020 such a socket
cherishing is needed only for Windows. But I allow that with with some
other systems and/or a real network the data sent just before exit can
be lost.
Best regards,
Alexander