Re: libpq compression

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Daniil Zakhlystov <usernamedt(at)yandex-team(dot)ru>, Konstantin Knizhnik <knizhnik(at)garret(dot)ru>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: libpq compression
Date: 2021-02-22 20:44:30
Message-ID: 3604970.1614026670@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> So at the end of the day I'm not really quite sure what is best here.
> I agree with all of Craig's points about the advantages of
> packet-level compression, so I'd really prefer to make that approach
> work if we can. However, it also seems to me that there's room to be
> fairly concerned about what these test results are showing.

BTW ... in view of the nearby thread about permanently disabling
OpenSSL's compression option, I wonder whether we really ought to be
in a hurry to put back compression underneath that. While this area
is out of my wheelhouse, my understanding of the problem with OpenSSL
is that the packet length changes due to compression can provide
enough information to an attacker to break the encryption. It seems
to me that do-it-ourselves compression would most likely create an
equivalent vulnerability.

Perhaps that problem can be dodged by refusing to use compression
if any form of encryption is in use ... but that would make for
another big reduction in the scope of usefulness of this feature.
Connections on which you'd care about compression are likely to be
across open networks where encryption is an even more pressing need.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2021-02-22 20:52:42 Re: Parser Hook
Previous Message Joel Jacobson 2021-02-22 20:42:44 Re: pg_attribute.attname inconsistency when renaming primary key columns