Re: An extra error for client disconnection on Windows

Hello, thanks for revewing and the discussion.

At Sat, 10 Sep 2016 10:44:50 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in <17326(dot)1473518690(at)sss(dot)pgh(dot)pa(dot)us>
> Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
> > On Fri, Sep 9, 2016 at 11:39 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> 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?

This "error" won't be raised when any side of NIC stopped. This
error is returned when the connection was "resetted", that is,
RST packet is sent and received from the peer. "connection reset"
is regarded as just a EOF at least for read() on Linux, I don't
think there's no problem to conceal the ECONNRESET on Windows if
we are satisfied with the behavior of Linux's read(). Users won't
know of the closed connections if a client doesn't show a message
for an EOF on Linux. Users will know of them on Windows if a
program shows a message for an EOF without a message for
ECONNRESET.

In another aspect is the policy of behavior unification.

If we take a policy to try to imitate the behavior of some
reference platform (specifically Linux) on other platforms, this
is required disguising. Another potential policy on this problem
is "following the platform's behavior". From this viewpoint, this
message should be shown to users because Windows says
so. Especially for socket operations, the simultion layer is
intending the former for non-error behaviors, but I'm not sure
about the behaviors on errors.

> It isn't an "error". These conditions get logged at COMMERROR which is
> effectively LOG_SERVER_ONLY.

If RST is not expected at the time and distinguishing it from FIN
is significant to users, it would be an "error".

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center