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
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 |