On Thu, Jun 29, 2017 at 7:29 PM, Satyanarayana Narlapuram
<Satyanarayana.Narlapuram@microsoft.com> wrote:
> -----Original Message-----
The formatting of this message differs from the style normally used on
this mailing list, and is hard to read.
> 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.)
>
> We can avoid one round trip if the server accepts the startupmessage as is (including understanding all the
parameterssupplied 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.
ProvidingMin version helps server enforce the client Min protocol version, and provides a path to deprecate older
versions.Thoughts?
With this latest proposal, there are no extra round-trips anyway. I
don't much see the point of having the server advertise a minimum
supported version. The idea of new minor protocol versions is to add
*optional* features, so there shouldn't be an issue with the client
being too old to talk to the server altogether. Of course, the server
might be configured to reject the client unless some particular new
feature is in use, but that's best handled by a message about the
specific problem at hand rather than a generic complaint.
> 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.
Nothing in that proposal involved an extra connection setup process;
if that's not clear, you might want to reread it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company