Re: protocol version negotiation (Re: [HACKERS] Libpq PGRES_COPY_BOTH- version compatibility) - Mailing list pgsql-hackers

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Robert Haas
Sent: Thursday, June 29, 2017 5:18 AM
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Craig Ringer <craig@2ndquadrant.com>; Peter Eisentraut <peter_e@gmx.net>; Magnus Hagander <magnus@hagander.net>;
PostgreSQL-development<pgsql-hackers@postgresql.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
justcoin a version of libpq for every server release; e.g. whatever PostgreSQL 11 ships is version 3.11, etc.  It
includesany 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
Azuredatabase for PostgreSQL service (host name, and connection id in the startupmessage). For someone wondering what
theyare, 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
highestversion it supports, and ignores any pg_protocol.<whatever> options not known to it as being either third-party
extensionsor something from a future version.  If the initial response to the startup message is anything other than a
ServerProtocolVersionmessage, the client should assume it's talking to a 3.0 server.  (To make this work, we would
back-patcha change into existing releases to allow any 3.x protocol version and ignore any pg_protocol.<whatever>
optionsthat were specified.)
 

> If the client version is anything other than 3.0, the server responds with a ServerProtocolVersion indicating the
highestversion it supports, and ignores any pg_protocol.<whatever> options not known to it as being either third-party
extensionsor something from a future version.  If > the initial response to the startup message is anything other than
aServerProtocolVersion message, the client should assume it's talking to a 3.0 server.  (To make this work, we would
back-patcha 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
suppliedby the client), and in the cases where server couldn’t accept the startupmessage / require negotiation, it
shouldsend ServerProtocolVersion message that contains both MIN and MAX versions it can support. Providing Min version
helpsserver 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
isconfigured to require the use of whizzbang-2 security, and the client protocol version indicates that at most
whizzbang-1.9is available, then the server can close the       > connection with a suitable complaint; conversely, if
theconnection string had require_whizzbang=2, and the server is too old to support that, then the client can decide to
bailout 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
throughconnection setup process again? The state machine may not sound simple with this proposal but helps bringing
downtotal time taken for the login.
 
Client / server can disconnect any time they think the negotiation failed.


Thanks,
Satya