Re: Experiments with Postgres and SSL

Поиск
Список
Период
Сортировка
От Vladimir Sitnikov
Тема Re: Experiments with Postgres and SSL
Дата
Msg-id CAB=Je-GZnPHFrro-LQ12P4h1WtGu_CX7JMgbmY5zW89PF7twKQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Experiments with Postgres and SSL  (Greg Stark <stark@mit.edu>)
Список pgsql-hackers
>You could just hard code that servers newer than a
> specific version would have this support

Suppose PostgreSQL 21 implements "fast TLS"
Suppose pgjdbc 43 supports "fast TLS"
Suppose PgBouncer 1.17.0 does not support "fast TLS" yet

If pgjdbc connects to the DB via balancer, then the server would
respond with "server_version=21".
The balancer would forward "server_version", so the driver would
assume "fast TLS is supported".

In practice, fast TLS can't be used in that configuration since the
connection will fail when the driver attempts to ask
"fast TLS" from the PgBouncer.

> Or it could be done with a "protocol option"

Would you please clarify what you mean by "protocol option"?

>I guess a lot depends on the way the driver works and the way the
> application is structured

There are cases when applications pre-create connections on startup,
so the faster connections are created the better.
The same case happens when the admin issues "reset connection pool",
so it discards old connections and creates new ones.
People rarely know all the knobs, so I would like to have a "fast by
default" design (e.g. server sending a notification "you may use fast
mode the next time")
rather than "keep old behaviour and require everybody to add fast=true
to their configuration" (e.g. users having to configure
"try_fast_tls_first=true")

Vladimir



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: run pgindent on a regular basis / scripted manner
Следующее
От: Gurjeet Singh
Дата:
Сообщение: Re: Named Operators