Re: Rare SSL failures on eelpout

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Rare SSL failures on eelpout
Date: 2019-03-19 00:27:37
Message-ID: CA+hUKG+jQOiinPisVyGDY8sPy2WHNibu_PAB6VXqYD5ALSgxkA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 19, 2019 at 12:44 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> > Shouldn't we also back-patch the one-line change adding
> > pqHandleSendFailure()?
>
> As I said before, I don't like that patch: at best it's an abuse of
> pqHandleSendFailure, because that function is only meant to be called
> at start of a query cycle. It wouldn't be hard to break this usage and
> not notice, especially given that we often don't test back-patched
> changes very carefully in the back branches if they seem OK in HEAD.
>
> Possibly we could consider back-patching the more aggressive patch
> once it's survived v12 beta testing, and just living with the issue
> till then. Given what we know now, I don't think this is a big
> problem for the field: how many people use SSL on local connections?

Yeah, now that we understand this properly I agree this is unlikely to
bother anyone in real life. I just want to make the build farm green.
I wondered about ssl_max_protocol_version = 'TLSv1.2', but that GUC's
too new. Another option would be to change the "command_fails_like"
pattern to tolerate both errors in v11.

--
Thomas Munro
https://enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2019-03-19 00:31:47 Re: [HACKERS] Block level parallel vacuum
Previous Message Thomas Munro 2019-03-19 00:14:44 Re: Rare SSL failures on eelpout