| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Rare SSL failures on eelpout |
| Date: | 2019-03-18 23:44:37 |
| Message-ID: | 9626.1552952677@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> On Tue, Mar 19, 2019 at 9:11 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> My current feeling is that this is OK to put in HEAD but I think the
>> risk-reward ratio isn't very good for the back branches. Even with
>> an OpenSSL version where this makes a difference, the problematic
>> behavior is pretty hard to hit. So I'm a bit inclined to do nothing
>> in the back branches.
> 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?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2019-03-18 23:59:56 | Re: Making all nbtree entries unique by having heap TIDs participate in comparisons |
| Previous Message | Tom Lane | 2019-03-18 23:35:17 | pg_upgrade version checking questions |