On Thu, Jun 29, 2017 at 7:29 PM, Satyanarayana Narlapuram <satyanarayana.narlapu...@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 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? 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 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. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
