Re: Disable OpenSSL compression

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: Disable OpenSSL compression
Дата
Msg-id 20111108184645.GW24234@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: Disable OpenSSL compression  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> The fact of the matter is that in most situations where you want SSL,
> ie links across insecure WANs, compression is a win.  Testing a local
> connection, as you seem to have done, is just about 100% irrelevant to
> performance in the real world.

I'm mystified by the idea that SSL shouldn't be used on local networks.
If the only things talking to the database are other servers on
physically secure networks, perhaps, but when you've got databases
exposed (even through firewalls) to client networks (which are in the
same building), and any data that's even remotely sensetive, you should
be using SSL or IPSEC.  The chances of eaves-dropping on a typiacal WAN
physical/dedicated link (not over the Internet..) are actually much less
than some disgruntled employee spoofing the local switches to monitor
someone else's traffic.  For starters, you're going to need some pretty
specialized gear to eavesdrop on a T1 or similar link and once it's past
the last mile and into the fibre network...  Well, there's some folks
who can manage that, but it's not very many.

> There might be some argument for providing a client option to disable
> compression, but it should not be forced, and it shouldn't even be the
> default.  But before adding YA connection option, I'd want to see some
> evidence that it's useful over non-local connections.

I agree that it should be an option and that it should be on by default.
It's going to typically be a win.
Thanks,
    Stephen

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Boszormenyi Zoltan
Дата:
Сообщение: Re: DatumGetInetP buggy
Следующее
От: Tom Lane
Дата:
Сообщение: Re: ERROR: MergeAppend child's targetlist doesn't match MergeAppend