Message-ID: <4FDC05B6.9010301@timbira.com>
Date: Sat, 16 Jun 2012 01:04:06 -0300
From: Euler Taveira <euler@timbira.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.4) Gecko/20120510 Icedove/10.0.4
MIME-Version: 1.0
To: Magnus Hagander <magnus@hagander.net>
CC: Tom Lane <tgl@sss.pgh.pa.us>, Florian Pflug <fgp@phlo.org>,
	Bruce Momjian <bruce@momjian.us>,
	Pgsql Hackers <pgsql-hackers@postgresql.org>
Subject: Re: libpq compression
References: <4FD9698F.2090407@timbira.com> <29853.1339651170@sss.pgh.pa.us>
	<4FD9E70B.9040607@timbira.com> <11502.1339699384@sss.pgh.pa.us>
	<20120615021938.GA21704@momjian.us>
	<CABUevEyv4T+1gR6_Uqm_1qUD9PNDg6UdXbJhwHZgFi9hpQQ6NQ@mail.gmail.com>
	<F3B8BAA6-23E9-423A-A7D1-D2E14769F326@phlo.org>
	<CABUevExi-cJ6AvF2kDOy+qQsB+0JHofrcvVmNVoJ2HziZMMaAg@mail.gmail.com>
	<22690C61-E960-4A2A-BFD5-DAD3D3B5C474@phlo.org>
	<CABUevEzVpqS5RCLz2fFREdPFkuYkEKsrMpnfPixYWPki2=iJOA@mail.gmail.com>
	<4FDB954F.9010606@timbira.com> <5136.1339799120@sss.pgh.pa.us>
	<5365.1339799869@sss.pgh.pa.us>
	<CABUevEz_V4YYc0tUhkC6KD2GddysM5Z76pcHcMYiMDd7dwMxVQ@mail.gmail.com>
In-Reply-To: 
 <CABUevEz_V4YYc0tUhkC6KD2GddysM5Z76pcHcMYiMDd7dwMxVQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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, Suporte 24x7 e Treinamento