Re: Removing SSL renegotiation (Was: Should we back-patch SSL renegotiation fixes?)

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Removing SSL renegotiation (Was: Should we back-patch SSL renegotiation fixes?)
Date: 2015-06-27 06:07:05
Message-ID: CAB7nPqTJb-syo8KN0_Ar5+A6C0F8LQ+t7UDnskYFQeVybA+5Cg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Jun 27, 2015 at 6:12 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
>> On 2015-06-24 16:41:48 +0200, Andres Freund wrote:
>>> I, by now, have come to a different conclusion. I think it's time to
>>> entirely drop the renegotiation support.
>
>> I think by now we essentially concluded that we should do that. What I'm
>> not sure yet is how: Do we want to rip it out in master and just change
>> the default in the backbranches, or do we want to rip it out in all
>> branches and leave a faux guc in place in the back branches. I vote for
>> the latter, but would be ok with both variants.
>
> I think the former is probably the saner answer. It is less likely to
> annoy people who dislike back-branch changes. And it will be
> significantly less work, considering that that code has changed enough
> that you won't be able to just cherry-pick a removal patch. I also fear
> there's a nonzero chance of breaking stuff if you're careless about doing
> the removal in one or more of the five active back branches ...

+1 for removing on master and just disabling on back-branches.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2015-06-27 06:58:17 Re: checkpointer continuous flushing
Previous Message Amit Kapila 2015-06-27 04:45:38 drop/truncate table sucks for large values of shared buffers