| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Cc: | Greg Stark <stark(at)mit(dot)edu>, Andrey Borodin <amborodin86(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Jacob Champion <jchampion(at)timescale(dot)com>, Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com> |
| Subject: | Re: Experiments with Postgres and SSL |
| Date: | 2023-07-04 23:33:07 |
| Message-ID: | ZKSsM5y2uk4xAh4D@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jul 04, 2023 at 05:15:49PM +0300, Heikki Linnakangas wrote:
> I don't see the point of the libpq 'sslalpn' option either. Let's send ALPN
> always.
>
> Admittedly having the options make testing different of combinations of old
> and new clients and servers a little easier. But I don't think we should add
> options for the sake of backwards compatibility tests.
Hmm. I would actually argue in favor of having these with tests in
core to stress the previous SSL hanshake protocol, as not having these
parameters would mean that we rely only on major version upgrades in
the buildfarm to test the backward-compatible code path, making issues
much harder to catch. And we still need to maintain the
backward-compatible path for 10 years based on what pg_dump and
pg_upgrade need to support.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2023-07-04 23:39:19 | Re: Deleting prepared statements from libpq. |
| Previous Message | Thomas Munro | 2023-07-04 23:27:26 | Re: check_strxfrm_bug() |