Re: libpq compression - Mailing list pgsql-hackers

From Euler Taveira
Subject Re: libpq compression
Date
Msg-id 4FDC05B6.9010301@timbira.com
Whole thread Raw
In response to Re: libpq compression  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
On 16-06-2012 00:43, Magnus Hagander wrote:
> 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.
> 
That's exactly the complexity I wouldn't add to the code. I'm in favor of
experimenting an standard algorithm (zlib, for example -- let's say, it is the
easiest way to implement it) or even hooks (libpq and backend -- that seems to
be complex but less than openssl-backed connection just for compression).


--   Euler Taveira de Oliveira - Timbira       http://www.timbira.com.br/  PostgreSQL: Consultoria, Desenvolvimento,
Suporte24x7 e Treinamento
 


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Streaming-only Remastering
Next
From: Marko Kreen
Date:
Subject: Re: libpq compression