Re: Recent vendor SSL renegotiation patches break PostgreSQL

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Chris Campbell <chris_campbell(at)mac(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Recent vendor SSL renegotiation patches break PostgreSQL
Date: 2010-02-22 19:57:01
Message-ID: 117.1266868621@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> 2010/2/22 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>>> One way to deal with it would be to expose the whole renegotiation
>>> setting as a user configuratble option. So they can set *when* we
>>> renegotiate, which would also let them turn it off completely.
>>
>> Well, that might be a reasonable thing to do, because it's not just a
>> temporary kluge (that we won't know when to remove) but is adding an
>> arguably-useful-in-other-ways knob.

> You'd still have to turn it off on the server side if you have a
> *single* client that has the broken patch, but that's still a lot
> better than nothing.

Well, if it's a GUC it can be set per-user or per-database, so there's
at least some hope of not having to turn it off for everyone.

> Think it's worth taking a stab at?

If you want to do it, I'd be fine with it.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jaime Casanova 2010-02-22 20:08:25 Re: tie user processes to postmaster was:(Re: [HACKERS] scheduler in core)
Previous Message Tom Lane 2010-02-22 19:53:08 Re: tie user processes to postmaster was:(Re: [HACKERS] scheduler in core)