Re: Should we back-patch SSL renegotiation fixes? - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Should we back-patch SSL renegotiation fixes?
Date
Msg-id 20150624144950.GG3289@postgresql.org
Whole thread Raw
In response to Re: Should we back-patch SSL renegotiation fixes?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> >> On Tue, Jun 23, 2015 at 2:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >>> I do not know at this point whether these behaviors are really the same
> >>> bug or not, but I wonder whether it's time to consider back-patching the
> >>> renegotiation fixes we did in 9.4.  Specifically, I think maybe we should
> >>> back-patch 31cf1a1a4, 86029b31e, and 36a3be654.
> 
> > Yes, +1 for backpatching.  Don't forget 5674460b and b1aebbb6.
> 
> Huh?  5674460b is ancient, and we concluded that b1aebbb6 didn't represent
> anything much more than cosmetic fixes.

Sorry, I mixed up 5674460b with 36a3be65 which you already mentioned ...
and I see that because of the conclusions from 272923a0a695 then the
one-char change in b1aebbb6 is not very interesting.

I do think that perhaps we should simplify the code down to what
272923a0a695 + 1c2b7c0879d8 do.


I also agree that the other changes by Andres and Heikki, which involve
making all communication use a nonblocking socket, seem too invasive to
backpatch; even with the insurance provided by beta+release, the
disruptiveness of changes seems a bit too high, considering that
387da18874a apparently cannot be used without 4f85fde8eb which is a bit
scary in itself.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: UPSERT on partition
Next
From: Tom Lane
Date:
Subject: Re: Removing SSL renegotiation (Was: Should we back-patch SSL renegotiation fixes?)