Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs - Mailing list pgsql-hackers

From Jelte Fennema-Nio
Subject Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs
Date
Msg-id CAGECzQRbktH-VFDwe=Mw+Sp2sM0yF48XdYW-X4avTap_mB+XvA@mail.gmail.com
Whole thread Raw
In response to Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-hackers
On Tue, 20 Aug 2024 at 19:02, David G. Johnston
<david.g.johnston@gmail.com> wrote:
> So basically my proposal amounted to making every update a "major version update" and changing the behavior
surroundingNegotiateProtocolVersion so it applies to major version differences.  I'll stand by that change in
definition. The current one doesn't seem all that useful anyway, and as we only have a single version, definitely
hasn'tbeen materially implemented.  Otherwise, at some point a client that knows both v3 and v4 will exist and its
connectionwill be rejected instead of downgraded by a v3-only server even though such a downgrade would be possible.  I
suspectwe'd go ahead and change the rule then - so why not just do so now, while getting rid of the idea that minor
versionsare a thing. 

If we decide to never change the format of the StartupMessage again
(which may be an okay thing to decide). Then I agree it would make
sense to update the existing supported servers ASAP to be able to send
back a NegotiateProtocolVersion message if they receive a 4.x
StartupMessage, and the server only supports up to 3.x.

However, even if we do that, I don't think it makes sense to start
using the 4.0 version straight away. Because many older postgres
servers would still throw an error when receiving the 4.x request. By
using a 3.x version we are able to avoid those errors in the existing
ecosystem. Basically, I think we should probably wait ~5 years again
until we actually use a 4.0 version.

i.e. I don't see serious benefits to using 4.0.  The main benefit you
seem to describe is: "it's theoretically cleaner to use major version
bumps". And there is a serious downside: "seriously breaking the
existing ecosystem".

> I suppose we could leave minor versions for patch releases of the main server version - which still leaves the first
newfeature of a release incrementing the major version.  That would be incidental to changing how we handle major
versions.

Having a Postgres server patch update change the protocol version that
the server supports sounds pretty scary to me.



pgsql-hackers by date:

Previous
From: Sami Imseih
Date:
Subject: Re: Restart pg_usleep when interrupted
Next
From: Jelte Fennema-Nio
Date:
Subject: Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs