Re: BUG #16678: The ecpg connect/test5 test sometimes fails on Windows

24.10.2020 20:39, Tom Lane wrote:
> Alexander Lakhin <exclusion@gmail.com> writes:
>> 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.
> I'm afraid this cure is probably worse than the disease, because
> now the backend's exiting is held hostage by whether the client
> closes its socket (and the resulting FIN reaches us, which it
> might not if there's a network problem).
On a next level of this game we could make something like that:
        secure_close(MyProcPort);
        timeout = 1000; // 1 sec
        setsockopt(MyProcPort->sock, SOL_SOCKET, SO_RCVTIMEO,
(char*)&timeout, sizeof(timeout));
        shutdown(MyProcPort->sock, SD_SEND);
        for(;;) {
            char buffer[1000];
            int res = recv(MyProcPort->sock, buffer, 1000, 0);
            if (res <= 0) {
                break;
            }
        }
        closesocket(MyProcPort->sock);
(I can't get this timeout working yet.)

But I'm inclined to stay on the previous level with "shutdown &&
closesocket" as recommended for server side:
https://docs.microsoft.com/en-us/windows/win32/winsock/graceful-shutdown-linger-options-and-socket-closure-2
Please look at the draft patch.

By the way, the delay added to pqReadData():
    pg_usleep(10000L); // Wait for 10 ms.
makes the src/test/recovery test fail on Linux too (pg_ctl can't stop
the primary node).
So it seems that slow reading from a socket breaks things not only on
Windows and the fix should be more comprehensive.

Best regards,
Alexander