Re: protocol version negotiation (Re: Libpq PGRES_COPY_BOTH - version compatibility)

-----Original Message-----
From: pgsql-hackers-owner(at)postgresql(dot)org [mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of Robert Haas
Sent: Thursday, June 29, 2017 5:18 AM
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Craig Ringer <craig(at)2ndquadrant(dot)com>; Peter Eisentraut <peter_e(at)gmx(dot)net>; Magnus Hagander <magnus(at)hagander(dot)net>; PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: protocol version negotiation (Re: [HACKERS] Libpq PGRES_COPY_BOTH - version compatibility)

> 1. The client sends a StartupMessage 3.x for version 3.x. We could bump the version explicitly, or perhaps we should just coin a version of libpq for every server release; e.g. whatever PostgreSQL 11 ships is version 3.11, etc. It includes any protocol options that don't exist today as > pg_protocol.<whatever> in the startup packet.

+1 on this. Happy to read this conversation. I am hopeful that this provides us a path to include parameters needed for Azure database for PostgreSQL service (host name, and connection id in the startupmessage). For someone wondering what they are, please see the threads below.

https://www.postgresql.org/message-id/DM2PR03MB416343FC02D6E977FEF2EB191C00%40DM2PR03MB416.namprd03.prod.outlook.com
https://www.postgresql.org/message-id/DM2PR03MB4168F3C796B2965FDC4CF9991C00%40DM2PR03MB416.namprd03.prod.outlook.com

2. If the client version is anything other than 3.0, the server responds with a ServerProtocolVersion indicating the highest version it supports, and ignores any pg_protocol.<whatever> options not known to it as being either third-party extensions or something from a future version. If the initial response to the startup message is anything other than a ServerProtocolVersion message, the client should assume it's talking to a 3.0 server. (To make this work, we would back-patch a change into existing releases to allow any 3.x protocol version and ignore any pg_protocol.<whatever> options that were specified.)

> If the client version is anything other than 3.0, the server responds with a ServerProtocolVersion indicating the highest version it supports, and ignores any pg_protocol.<whatever> options not known to it as being either third-party extensions or something from a future version. If > the initial response to the startup message is anything other than a ServerProtocolVersion message, the client should assume it's talking to a 3.0 server. (To make this work, we would back-patch a change into existing releases to allow any 3.x protocol version and ignore any > pg_protocol.<whatever> options that were specified.)

We can avoid one round trip if the server accepts the startupmessage as is (including understanding all the parameters supplied by the client), and in the cases where server couldn’t accept the startupmessage / require negotiation, it should send ServerProtocolVersion message that contains both MIN and MAX versions it can support. Providing Min version helps server enforce the client Min protocol version, and provides a path to deprecate older versions. Thoughts?

> If either the client or the server is unhappy about the age of the other, then it can disconnect; e.g. if the server is configured to require the use of whizzbang-2 security, and the client protocol version indicates that at most whizzbang-1.9 is available, then the server can close the > connection with a suitable complaint; conversely, if the connection string had require_whizzbang=2, and the server is too old to support that, then the client can decide to bail out when it receives the ServerProtocolVersion message.

Does the proposal also include the client can negotiate the protocol version on the same connection rather than going through connection setup process again? The state machine may not sound simple with this proposal but helps bringing down total time taken for the login.
Client / server can disconnect any time they think the negotiation failed.

Thanks,
Satya