Thomas Munro <thomas.munro@gmail.com> writes:
> With a simple socket test program I can see that if you send a single
> packet after the remote end has closed and after it had already read
> everything you sent it up to now, you get EPIPE. If there was some
> outstanding data from a previous send that it hadn't read yet when it
> closed its end, you get ECONNRESET. This doesn't happen if client and
> server are on different machines, or on FreeBSD even on the same
> machine, but does happen if client and server are on the same Linux
> system (whether using the loopback interface or a real network
> interface). However, after you get ECONNRESET, you can still read the
> final data that was sent by the server before it closed, which
> presumably contains the error we want to report to the user. That
> suggests that we could perhaps handle ECONNRESET both at startup
> packet send time (for certificate rejection, eelpout's case) and at
> initial query send (for idle timeout, bug #15598's case) by attempting
> to read. Does that make sense?
Hmm ... it definitely makes sense that we shouldn't assume that a *write*
failure means there is nothing left to *read*. I would say that's
generally true regardless of the specific errno. How about the opposite
case, btw --- should we continue to try to flush data after a read
error? Or is it safe to assume that means the other end is gone?
> I haven't poked into the libpq state
> machine stuff to see if that would be easy or hard.
Me either.
regards, tom lane
