Re: Slowness of extended protocol

Поиск
Список
Период
Сортировка
От Vladimir Sitnikov
Тема Re: Slowness of extended protocol
Дата
Msg-id CAB=Je-EYSeLCmg8p+1df=H4dwZxqVe8s6cREvoob7bzMJknaHg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Slowness of extended protocol  (Shay Rojansky <roji@roji.org>)
Ответы Re: Slowness of extended protocol  (Shay Rojansky <roji@roji.org>)
Список pgsql-hackers
Shay Rojansky <roji@roji.org>:

That sounds right to me. As you say, the server version is sent early in the startup phase, before any queries are sent to the backend, so frontends know which server they're communicating with.

We could call this "protocol 3.1" since it doesn't break backwards compatibility (no incompatible server-initiated message changes, but it does include a feature that won't be supported by servers which only support 3.0. This could be a sort of "semantic versioning" for the protocol - optional new client-initiated features are a minor version bump, others are a major version bump...

Adding a new message is not backward compatible since it will fail in pgbouncer kind of deployments.
Suppose there's "new backend", "old pgbouncer", "new client" deployment.
If the client tries to send the new message, it will fail since pgbouncer would have no idea what to do with that new message.

On the other hand, usage of some well-defined statement name to trigger the special case would be fine: all pgbouncer versions would pass those parse/bind/exec message as if it were regular messages.

Vladimir

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

Предыдущее
От: Ashutosh Bapat
Дата:
Сообщение: Re: Declarative partitioning
Следующее
От: Victor Wagner
Дата:
Сообщение: Re: handling unconvertible error messages