Re: Recent vendor SSL renegotiation patches break PostgreSQL
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Magnus Hagander <magnus@hagander.net>
Cc: Bruce Momjian <bruce@momjian.us>, Chris Campbell <chris_campbell@mac.com>, Robert Haas <robertmhaas@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2010-02-24T16:47:09Z
Lists: 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