On Sat, Jun 16, 2012 at 6:37 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > I wrote: >> Euler Taveira <eu...@timbira.com> writes: >>> I see the point in not adding another dependencies or reinventing the wheel >>> but I see more drawbacks than benefits in adopting a SSL-based compression. > >> In the end, judging this tradeoff is a matter of opinion, but I come to >> the opposite conclusion. > > BTW, there is an additional technical argument that I don't think has > been made yet. Assume that we implement our own transport compression, > and then somebody runs an SSL connection using a recent OpenSSL version > (in which, IIRC, SSL-level compression is enabled by default). Now, > OpenSSL is trying to compress already-compressed data. That's not > merely a waste of cycles but is very likely to be counterproductive, > ie recompressed data usually gets larger not smaller. > > We could possibly address this by adding control logic to tell OpenSSL > not to compress ... but that's almost exactly the code you don't want > to write, just making a different option selection. And I wonder > whether SSL implementations that don't support compression will accept > a set-the-compression-option call at all.
Yes, but there's also a lot of such awkward logic we need to add if we *do* go with the SSL library doing the compression: For example, we can no longer trust the SSL library to always do encryption, since we specifically want to support null encryption. Meaning we need to teach pg_hba to treat a connection with null encryption as hostnossl, even if it's an openssl-backed connection, and mirrored. And in libpq, we have to make sure that a requiressl connection *does* fail even if we have ssl, when we're using null encryption. And we currently have no way to specify different encryption options on a per-host basis, which is something we'd have to do (e.g. i want to be able to say that "subnet x requires encryption with these encryptions methods" and "subnet y doesn't require encryption but should do compression". Which in the easiest first look would require ssl_ciphers to be controllable from pg_hba.conf - but that doesn't work since we don't get to pg_hba.conf until after we've negotiated the SSL mode... So there's quite a bit of complexity that needs to be put in there just to deal with the fact that we're using SSL to do compression, if we want to support it in a way that's not hackish. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
