Horton

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

David G. Johnston <david.g.johnston@gmail.com>

View thread
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Jacob Champion <jacob.champion@enterprisedb.com>
Cc: Jelte Fennema-Nio <postgres@jeltef.nl>, Robert Haas <robertmhaas@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>, Tom Lane <tgl@sss.pgh.pa.us>, Jacob Burroughs <jburroughs@instructure.com>, Dave Cramer <davecramer@gmail.com>, Peter Smith <smithpb2250@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, "Andrey M. Borodin" <x4mmm@yandex-team.ru>, Pavel Stehule <pavel.stehule@gmail.com>, Jeff Davis <pgsql@j-davis.com>, Peter Eisentraut <peter@eisentraut.org>, Daniele Varrazzo <daniele.varrazzo@gmail.com>
Date: 2024-08-20T17:21:54Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. libpq: Add min/max_protocol_version connection options

  2. libpq: Handle NegotiateProtocolVersion message differently

  3. Add PQfullProtocolVersion() to surface the precise protocol version.

  4. Do not hardcode PG_PROTOCOL_LATEST in NegotiateProtocolVersion

  5. libpq: Handle NegotiateProtocolVersion message

  6. Provide for forward compatibility with future minor protocol versions.

On Tue, Aug 20, 2024 at 10:03 AM Jacob Champion <
jacob.champion@enterprisedb.com> wrote:

> On Tue, Aug 20, 2024 at 7:26 AM Jelte Fennema-Nio <postgres@jeltef.nl>
> wrote:
> > In practical terms I think that means for a minor version bump the
> > format of the StartupMessage cannot be changed. Changing anything else
> > is fair game for a minor protocol version bump.
>
> I may be in a tiny minority here, but when I combine that statement
> with your opinion from way upthread that
>
> > IMHO, we
> > should get to a state where protocol minor version bumps are so
> > low-risk that we can do them whenever we add message types
>
> To me it seems that what you're proposing is indistinguishable from
> what most other protocols would consider a major version bump; it's
> just that you (reasonably) want existing clients to be able to
> negotiate multiple major versions in one round trip.
>
>
This makes more sense to me - a major version change is one where the
server fails to understand the incoming message(s) to the point that it
cannot make decisions based upon contents.

Framed up this way the two-part versioning works just fine and I concur
that PQversionNumber should go ahead and report 10000+minor (starting at 2)
with 3.0 remaining as-is since apparently negotiation down to 3.0 is
possible here if the intermediate and/or final server have such ability.

Still, instead of just failing immediately if 30002 is specified and
rejected, falling back to trying 3.0 - unless configured to either not do
that or to only do 3.0 - is advised to help with the transition.

David J.