From: | Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com> |
---|---|
To: | Greg Stark <stark(at)mit(dot)edu> |
Cc: | Andrey Borodin <amborodin86(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Experiments with Postgres and SSL |
Date: | 2023-01-20 06:40:19 |
Message-ID: | CAB=Je-ENhbGt96K-W2qcTx-V5e3yOM964p3dRiNWDZb=4_E6bQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>I don't think it's worth implementing a code path in
> the server like this as it would then become cruft that would be hard
> to ever get rid of.
Do you think the server can de-support the old code path soon?
> I think you can do the same thing, more or less, in the client. Like
> if the driver tries to connect via SSL and gets an error it remembers
> that host/port and connects using negotiation in the future.
Well, I doubt everybody would instantaneously upgrade to the database that
supports fast TLS,
so there will be a timeframe when there will be a lot of old databases, and
the clients will be new.
In that case, going with "try fast, ignore exception" would degrade
performance for old databases.
I see you suggest caching, however, "degrading one of the cases" might be
more painful than
"not improving one of the cases".
I would like to refrain from implementing "parallel connect both ways
and check which is faster" in
PG clients (e.g. https://en.wikipedia.org/wiki/Happy_Eyeballs ).
Just wondering: do you consider back-porting the feature to all supported
DB versions?
> In practice though, by the time drivers support this it'll probably be
> far enough in the future
I think drivers release more often than the database, and we can get driver
support even before the database releases.
I'm from pgjdbc Java driver team, and I think it is unfair to suggest that
"driver support is only far enough in the future".
Vladimir
From | Date | Subject | |
---|---|---|---|
Next Message | David Geier | 2023-01-20 06:43:00 | Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? |
Previous Message | Masahiko Sawada | 2023-01-20 06:17:51 | Re: Perform streaming logical transactions by background workers and parallel apply |