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