Re: Rare SSL failures on eelpout

Thomas Munro <thomas(dot)munro(at)gmail(dot)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