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

From Robert Haas
Subject Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs
Date
Msg-id CA+TgmoZiagMwcDNKK8CFMYFeQWAC8fKn0WF6o8mua3FW44Nk6Q@mail.gmail.com
Whole thread Raw
In response to Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs  (Jelte Fennema-Nio <postgres@jeltef.nl>)
Responses Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs
List pgsql-hackers
On Wed, Jun 5, 2024 at 10:06 AM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
> FYI Heikki his patchset is here:
> https://www.postgresql.org/message-id/flat/508d0505-8b7a-4864-a681-e7e5edfe32aa%40iki.fi
>
> Afaict there's no way to implement this with old clients supporting
> the new message. So it would need to be opt-in from the client
> perspective, either using a version bump or a protocol parameter (e.g.
> large_cancel=true). IMHO a version bump would make more sense for this
> one.

Well, hang on. The discussion on that thread suggests that this is
only going to break connections to servers that don't have
NegotiateProtocolVersion. Personally, I think that's fairly OK. It's
true that connections to, I guess, pre-9.3 servers will break, but
there shouldn't be tons of those left around. It's not great to break
connectivity to such servers, of course, but it seems kind of OK. What
I really don't want is for v18 to break connections to v17 servers.
That would be exponentially more disruptive.

I do take your point that poolers haven't added support for
NegotiateProtocolVersion yet, but I bet that will change pretty
quickly once there's a benefit to doing so. I think it's a lot easier
for people to install a new pooler version than a new server version,
because the server has the data in it. Also, it's not like they
haven't had time.

But the real question here is whether we think the longer cancel key
is really important enough to justify the partial compatibility break.
I'm not deathly opposed to it, but I think it's debatable and I'm sure
some people are going to be unhappy.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: Fix use of possible uninitialized variable retval (src/pl/plpgsql/src/pl_handler.c)
Next
From: Mark Dilger
Date:
Subject: Re: XLog size reductions: Reduced XLog record header size for PG17