Re: protocol version negotiation (Re: [HACKERS] Libpq PGRES_COPY_BOTH- version compatibility)

On 29 June 2017 at 20:18, Robert Haas <robertmhaas@gmail.com> wrote:

> I'm not sure if non-critical is exactly the right terminology.  What
> we want to do is distinguish between things that are intended as
> protocol-level options vs. things that are intended as GUCs.

We probably also need to be able to differentiate between "this
protocol option would be nice if you support it, please tell me in
your parameter status message if you managed to honour it" vs "this
connection request is invalid if you cannot honour this protocol
option, do not attempt to proceed".

If the option changes the meaning of the request entirely in some way
we probably don't want a server that doesn't understand carrying on
anyway.

But I think it's probably sufficient if the server's reply to the
client includes the options it was able to recognise and honour, so
the client can immediately nope out if it doesn't like the server's
lack of support for some option.

> Maybe we should instead pick a GUC namespace and reserve it for the
> use of protocol level options; e.g. pg_protocol.<anything> becomes
> invalid as the name of a GUC, but can be included in a startup packet
> (or do we need to pick something shorter, like _pg, to keep the
> message short?).  Servers ignore anything that they don't understand.
> So:

Yes, but something shorter probably, Tom's already expressed concerns
elsewhere about bandwidth use from reporting server_version_num and I
can't imagine numerous pg_protocol_blahblah entries being popular with
many people at all.

_pg_... seems sufficient IMO, we don't use that in GUCs to date, and
nobody's likely to.

Or to be consistent with protocol and libpq stuff, _pq_... ?

> 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.

Not a fan of bumping for the sake of it, it puts more work on 3rd
party drivers for what seems like no real gain.

Bump when we change something.

> 2. If the client version is anything other than 3.0, the server
> responds with a ServerProtocolVersion indicating the highest version
> it supports

Highest and lowest, I think Satyanarayana Narlapuram is right there.
Also which startup parameter protocol options were recognised and
honoured, so the client can immediately notice and bail if the server
didn't recognise something it requires. (think behaviour akin to
sslmode=require for _pg_starttls).

> and ignores any pg_protocol.<whatever> options not known
> to it as being either third-party extensions or something from a
> future version.

I think ignoring is fine if the server lists the ones it recognises in
its reply, per above.

> 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.)

Such a backpatch makes sense, and is pretty safe.

-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services