On 2015-12-30 13:26:34 -0500, Tom Lane wrote:
> I doubt that is what is happening here, because those errnos don't
> seem sensible for an EOF condition, but I'd still feel more comfortable
> if be_tls_read/be_tls_write handled SSL_ERROR_SYSCALL like this:
>
> if (n != -1)
> {
> errno = ECONNRESET;
> n = -1;
> }
> + else
> + {
> + /* just in case errno is EWOULDBLOCK/EAGAIN */
> + *waitfor = WL_SOCKET_READABLE | WL_SOCKET_WRITEABLE;
> + }
Being a bit more defensive here sounds sensible. But I think it might be
better to only set WL_SOCKET_READABLE/WL_SOCKET_WRITEABLE in
be_tls_read/be_tls_write correspondingly. It's possible that we'd
otherwise just end up in an endless loop.
Shay, if you trace the backend with process explorer or something like
that, what system calls do you seen when you kill the client?
Hm, so pgwin32_recv() has the following block: if (pgwin32_waitforsinglesocket(s, FD_READ | FD_CLOSE | FD_ACCEPT,
INFINITE) == 0) return -1; /* errno already set */
and there's several paths in pgwin32_waitforsinglesocket() that return
0. But I can't see any of those reasonably return EAGAIN/EWOULDBLOCK
Shay earlier said that he sees the connection in state FIN_WAIT_2. The
WSAEventSelect() docs say:
"The FD_CLOSE network event is recorded when a close indication is
received for the virtual circuit corresponding to the socket. In TCP
terms, this means that the FD_CLOSE is recorded when the connection goes
into the TIME WAIT or CLOSE WAIT states.".
To me that seems to imply that the socket Shay observed is the client's
and that the server should see at least see CLOSE WAIT.
Andres