Amit Kapila <> writes:
>   I think that still this kind of problems can be there at other
> places in code. I checked few places and suspecting secure_read() can
> also have similar problem:

> ereport(COMMERROR,
> errmsg("SSL error: %s", SSLerrmessage())));
> /* fall through */

Note that what it "falls through" to is "errno = ECONNRESET", so the
caller will see a well-defined value of errno after this.  Even without
the ereport call, I'd think that was necessary because SSL_get_error
isn't documented to return a meaningful value of errno except in the

> In general it is responsibility of caller to take care of errno
> handling, but I am not sure it is taken care well at all places in
> code and the chances of such problems were less earlier because there
> was less chance that ereport would reset errno, but now it will
> definitely do so.

[ shrug... ]  To my mind, this is a *good* thing, because now we will
more easily find and fix any callers that are broken.  They were broken
anyway, it's just that the circumstances might've been difficult to
reproduce.  As an example consider the possibility that ereport might
previously have stomped on errno only with unusual log_line_prefix

                        regards, tom lane

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to