Subject: Re: BUG #16678: The ecpg connect/test5 test sometimes fails on
 Windows
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-bugs@lists.postgresql.org
References: <16678-253e48d34dc0c376@postgresql.org>
 <434311.1603135136@sss.pgh.pa.us>
From: Alexander Lakhin <exclusion@gmail.com>
Message-ID: <f558fb39-ce9e-a516-d7c3-fc94fb581711@gmail.com>
Date: Sat, 24 Oct 2020 13:00:00 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <434311.1603135136@sss.pgh.pa.us>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Precedence: bulk

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