Re: An extra error for client disconnection on Windows

On Fri, Sep 9, 2016 at 11:39 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com> writes:
>> On Thu, Jun 2, 2016 at 6:51 PM, Kyotaro HORIGUCHI <
>> horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>>> After a process termination without PQfinish() of a client,
>>> server emits the following log message not seen on Linux boxes.
>>> LOG: could not receive data from client: An existing connection was
>>> forcibly closed by the remote host.
>>>
>>> This patch translates WSAECONNRESET of WSARecv to an EOF so that
>>> pgwin32_recv behaves the same way with Linux.
>
>> Marked the patch as "ready for committer".
>
> Windows is not my platform, but ... is this actually an improvement?
> I'm fairly concerned that this change would mask real errors that ought
> to get logged. I don't know that that's an okay price to pay for
> suppressing a log message when clients violate the protocol.
>
> According to
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms740668(v=vs.85).aspx
> WSAECONNRESET means:
>
> An existing connection was forcibly closed by the remote host. This
> normally results if the peer application on the remote host is
> suddenly stopped, the host is rebooted, the host or remote network
> interface is disabled, or the remote host uses a hard close (see
> setsockopt for more information on the SO_LINGER option on the remote
> socket). This error may also result if a connection was broken due to
> keep-alive activity detecting a failure while one or more operations
> are in progress. Operations that were in progress fail with
> WSAENETRESET. Subsequent operations fail with WSAECONNRESET.
>
> (The description of WSAENETRESET, on the same page, indicates that the
> last two sentences apply only to the keep-alive failure case.)
>
> So this change would deal nicely with the "peer application on the remote
> host is suddenly stopped" case, at the price of being not nice about any
> of the other cases. Not convinced it's a good tradeoff.

Yes, in the list of failure cases that could trigger this error, the
one that looks like a problem is to me is when a network interface is
disabled. It may be a good idea to let users know via the logs that
something was connected. Could we for example log a WARNING message,
and not report an error?
--
Michael