Re: Slowness of extended protocol

Shay Rojansky <roji(at)roji(dot)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

>