On Wednesday, November 9, 2011, Albe Laurenz wrote: > Christopher Browne wrote: > >> I think that JDBC and Npgsql should also support disabling > compression. > > > > That's the *real* problem here... > > > > You're quite right that if we allow controlling this on the libpq > > side, it is surely desirable to allow controlling this via JDBC, > > Npgsql, and other mechanisms people may have around. > [...] > > With that series of complications, I wonder if maybe the right place > > to control this is pg_hba.conf. > > I think that wouldn't work, because to query pg_hba.conf, you have to > know user and database, which come from the client side. > But the SSL negotiation takes place earlier, namely when the > connection is established. >
Oh, right, that's going to be a problem doing it there. > > > I wonder how many SSL parameters there are which would be worth trying > > to have available. I expect we'd benefit from looking at all the > > relevant ones at once, so as to not have the problem of hacking "one > > more" into place and perhaps doing it a bit differently each time. > > Sure, if anybody can think of any. A quick look at > "man SSL_CTX_set_options" didn't show me any, but then OpenSSL's > documentation is very bad (the page does not even mention > SSL_OP_NO_COMPRESSION) and I am no SSL expert. > Oh yeah, their docs are. Um. Yeah, let's leave it at that. I think the other one is to control which encryption options are available - but we already have a guc for that. Is the following proposal acceptable: > > - Add a GUC ssl_compression, defaulting to "on". > - Add a client option "sslcompression" and an environment variable > PGSSLCOMPRESSION, defaulting to "1". > Seems like the reasonable thing, yes. Compression will be disabled if either side refuses. > I assume OpenSSL takes care of this for us, right? We just have to set the flags on the connection? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
