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
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) |