Hi.
> I would argue that this is an OpenSSL bug: it should not be trying to
> write on a connection that it knows perfectly well is already dead.
> (It should know that, anyway, because the only way that pqReadData would
> be trying to close the connection is that it got an error indication
> from OpenSSL.)
May be, may be...
> Possibly we could work around the problem by disabling SIGPIPE during
> connection close, but I don't really see why we should have to do that.
While take a look at source of libpq, i have discover following:
while reading from pipe, you are gettingcase SSL_ERROR_ZERO_RETURN: SOCK_ERRNO_SET(ECONNRESET);
but why you'r do not check
SOCK_ERRNO != ECONNRESET
while closing ssl connection ?
i was trying this and all is work fine.
In function close_SSL you are call SSL_shutdown to shutdown ssl pipe.
But if you are already get ECONNRESET (by pear?), why you call whi funtcion?
From openssl docs.
SSL_shutdown - shuts down an active TLS/SSL connection. It sends the ``close
notify'' shutdown alert to the peer.
That's why i've got SIGPIPE.
> That's pretty much a waste of time, because all it tells you is whether
> the connection was good the last time a query was done. It is *not*
> intended as an active "ping".
Ok, i'll take it in my mind.
Alexey Zayats.