From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Euler Taveira <euler(at)timbira(dot)com>, Florian Pflug <fgp(at)phlo(dot)org>, Bruce Momjian <bruce(at)momjian(dot)us>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: libpq compression |
Date: | 2012-06-16 03:43:50 |
Message-ID: | CABUevEz_V4YYc0tUhkC6KD2GddysM5Z76pcHcMYiMDd7dwMxVQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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/
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2012-06-16 03:49:23 | Re: [COMMITTERS] pgsql: New SQL functons pg_backup_in_progress() and pg_backup_start_tim |
Previous Message | Magnus Hagander | 2012-06-16 03:39:49 | Re: libpq compression |