Re: Recent vendor SSL renegotiation patches break PostgreSQL - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Recent vendor SSL renegotiation patches break PostgreSQL
Date
Msg-id 8958.1267030029@sss.pgh.pa.us
Whole thread Raw
In response to Re: Recent vendor SSL renegotiation patches break PostgreSQL  (Magnus Hagander <magnus@hagander.net>)
Responses Re: Recent vendor SSL renegotiation patches break PostgreSQL  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
Magnus Hagander <magnus@hagander.net> writes:
> 2010/2/24 Tom Lane <tgl@sss.pgh.pa.us>:
>> Also, the coding seems a bit confused about whether the
>> ssl_renegotiation_limit GUC exists when USE_SSL isn't set. �I think we
>> have a project policy about whether GUCs should still exist when the
>> underlying support isn't compiled, but I forget what it is :-(.

> I personally find it highly annoying when a GUC goes away, so I'm all
> for always having them there. And I thought that was our policy for
> new ones, but I can't find a reference to it...

I see that ssl_ciphers is made to go away when USE_SSL isn't set,
so the most consistent thing in the near term would be to do the same.
Revisiting the whole issue seems like not material for back-patching.

>> Also the xreflabel for the variable in the docs isn't consistent,

> You mean add _limit to it, right?

Right.

>> SUSET seems less surprising to me. �I agree that it's hard to make
>> a concrete case for a user doing anything terribly bad with it,
>> but on the other hand is there much value in letting it be USERSET?

> The use case would be for example npgsql (or npgsql clients) being
> able to disable it from the client side, because they know they can't
> deal with it. Even in the case that the server doesn't know that.

Fair enough, USERSET it is then.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Recent vendor SSL renegotiation patches break PostgreSQL
Next
From: Heikki Linnakangas
Date:
Subject: Re: A thought on Index Organized Tables