Christopher Browne wrote:
>> I think that JDBC and Npgsql should also support disabling
compression.
>
> That's the *real* problem here...
>
> You're quite right that if we allow controlling this on the libpq
> side, it is surely desirable to allow controlling this via JDBC,
> Npgsql, and other mechanisms people may have around.
[...]
> With that series of complications, I wonder if maybe the right place
> to control this is pg_hba.conf.
I think that wouldn't work, because to query pg_hba.conf, you have to
know user and database, which come from the client side.
But the SSL negotiation takes place earlier, namely when the
connection is established.
> I wonder how many SSL parameters there are which would be worth trying
> to have available. I expect we'd benefit from looking at all the
> relevant ones at once, so as to not have the problem of hacking "one
> more" into place and perhaps doing it a bit differently each time.
Sure, if anybody can think of any. A quick look at
"man SSL_CTX_set_options" didn't show me any, but then OpenSSL's
documentation is very bad (the page does not even mention
SSL_OP_NO_COMPRESSION) and I am no SSL expert.
Is the following proposal acceptable:
- Add a GUC ssl_compression, defaulting to "on".
- Add a client option "sslcompression" and an environment variable PGSSLCOMPRESSION, defaulting to "1".
Compression will be disabled if either side refuses.
That way you can control the setting per client, but you can also
force it on clients that do not use libpq if you want.
Yours,
Laurenz Albe
