Wire protocol compression

From: Shay Rojansky <roji(at)roji(dot)org>
To: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Wire protocol compression
Date: 2016-04-21 06:19:21
Message-ID: CADT4RqCKfawgwa735s_brELaJ8ySutCC-u3iyLL_EEsJQDYFrg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I know this has been discussed before (
http://postgresql.nabble.com/Compression-on-SSL-links-td2261205.html,
http://www.postgresql.org/message-id/BANLkTi=Ba1ZCmBuwwn7M1wvPFioT=6N79g@mail.gmail.com),
but it seems to make sense to revisit this in 2016.

Since CRIME in 2012, AFAIK compression with encryption is considered
insecure, and the feature is removed entirely in the TLS 1.3 draft. In
addition (and because of that), many (most?) client TLS implementations
don't support compression (Java, .NET), meaning that a considerable number
of PostgreSQL users don't have access to compression.

Does it make sense to you guys to discuss compression outside of TLS? There
are potentially huge bandwidth savings which could benefit both WAN and
non-WAN scenarios, and decoupling this problem from TLS would make it both
accessible to everyone (assuming PostgreSQL clients follow). It would be a
protocol change though.

Shay

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2016-04-21 08:22:03 Re: Optimization for updating foreign tables in Postgres FDW
Previous Message Tom Lane 2016-04-21 05:14:15 Re: EXPLAIN VERBOSE with parallel Aggregate