Based on this report, I have developed the attached patch. Is this OK?

The idea is not to call SSL_shutdown() if errno == ECONNRESET.

---------------------------------------------------------------------------

Алексей Заяц wrote:
> 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 getting
> case 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.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Bruce Momjian <bruce@momjian.us> writes:
> ! if (SOCK_ERRNO != ECONNRESET)
> ! SSL_shutdown(conn->ssl);

Ummm ... what is this supposed to fix exactly, and what are the odds
that it will introduce resource leaks?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > ! if (SOCK_ERRNO != ECONNRESET)
> > ! SSL_shutdown(conn->ssl);
>
> Ummm ... what is this supposed to fix exactly, and what are the odds

I think the user was getting SIGPIPE on SSL_shutdown() of a closed
connection.

> that it will introduce resource leaks?

I don't know myself. If some SSL expert says it is OK, we apply it, if
not, we ignore the patch.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Bruce Momjian <bruce@momjian.us> writes:
> Tom Lane wrote:
>> Bruce Momjian <bruce@momjian.us> writes:
>>> ! if (SOCK_ERRNO != ECONNRESET)
>>> ! SSL_shutdown(conn->ssl);
>>
>> Ummm ... what is this supposed to fix exactly, and what are the odds

> I think the user was getting SIGPIPE on SSL_shutdown() of a closed
> connection.

It seems moderately improbable that by the time control arrives here,
errno still has anything to do with the last operation on the SSL
socket.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate