Re: could not accept SSL connection: Success

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Carla Iriberri <ciriberri(at)salesforce(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: could not accept SSL connection: Success
Date: 2022-01-20 00:32:33
Message-ID: YeitoS9IMBAiXzG1@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, Jan 20, 2022 at 09:05:35AM +1300, Thomas Munro wrote:
> Good news, I'm glad they nailed that down. I recall that this
> behaviour was a bit of a moving target in earlier versions:
>
> https://www.postgresql.org/message-id/CAEepm%3D3cc5wYv%3DX4Nzy7VOUkdHBiJs9bpLzqtqJWxdDUp5DiPQ%40mail.gmail.com

Ahh.. So you saw the same problem a couple of years back. This
thread did not catch much attention.

I don't think that it makes much sense to leave this unchecked as the
message is confusing as it stands. Perhaps we could do something like
the attached by adding a note about OpenSSL 3.0 to revisit this code
once we unplug support for 1.1.1 and avoiding the errno==0 case? The
frontend has its own ideas of socket failures as it requires thread
support, making things different with the backend, but it seems to me
that we could see cases where SOCK_ERRNO is also 0. That's mostly
what you suggested on the other thread.

The error handling changes are really cosmetic, so I'd rather leave
the back-branches out of that. Thoughts?
--
Michael

Attachment Content-Type Size
ssl-eof-errno.patch text/x-diff 2.0 KB

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2022-01-20 00:58:43 Re: could not accept SSL connection: Success
Previous Message Chris Travers 2022-01-19 21:25:59 Re: WAL Archiving and base backup