Re: libpq compression

On Sat, Jun 16, 2012 at 6:37 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I wrote:
>> Euler Taveira <euler(at)timbira(dot)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/