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

On 16/08/2024 15:55, Robert Haas wrote:
> On Thu, Aug 15, 2024 at 6:03 PM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>> On the default for "max_protocol_version": I'm pretty disappointed if we
>> cannot change the default to "latest". I realize that that won't work
>> with poolers that don't implement NegotiateProtocolVersion. But I'm
>> afraid if we make the new protocol version opt-in, no one will use it,
>> and the poolers etc still won't bother to implement
>> NegotiateProtocolVersion for years to come, if ever. We can revisit this
>> decision later in the release cycle though. But I'd suggest changing the
>> default to "latest" for now, so that more hackers working with
>> connection poolers will notice, and we get more testing of the new
>> protocol and the negotiation.
>
> In this regard, I think your proposed protocol change (bumping the
> cancel-key length) is different from all of the other protocol
> enhancement proposals that I can think of. Most people seem to be
> interested in adding an optional feature that some clients might want
> and other clients might not care about. Peter Eisentraut's transparent
> column encryption stuff is an example of that. What Jelte wants to do
> here is too, really, because while these facilities seem like they
> could be generally useful for poolers -- at least if we could agree on
> what to do and work out all the problems -- and could potentially be
> used by applications as well, there would no requirement that any
> particular application use any of the new facilities and many of them
> wouldn't. So in that kind of world, it makes more sense to me to
> default to 3.0 unless the user indicates a desire to use a newer
> feature. That way, we minimize breakage at very little cost. Desire to
> use the new features can be expected to spur some development in
> ecosystem projects, and until that work gets done, many setups are
> unaffected.
>
> But the cancel key is a whole different kind of thing. I don't expect
> people to be motivated to add support for newer protocol versions just
> to get a longer cancel key. If we want people to adopt longer cancel
> keys, we need to change the client default and accept that there's
> going to be a bunch of breakage until everybody fixes their code.

Agreed.

> But is that actually a good idea?
>
> I have some misgivings about that. When somebody's stuff stops working
> because of some problem that boils down to "we made the cancel key
> longer," I think we're going to have some pretty irate users. I
> believe everybody would agree in a vacuum that making cancel keys
> longer is probably a good idea, but it seems like a relatively minor
> benefit for the amount of inconvenience we're going to be imposing on
> everyone.

Agreed.

> On the other hand, the logical conclusion of that argument
> is that we should never do it, which I don't really believe either.
> I'm actually kind of surprised that nobody else (that I've seen,
> anyway) has expressed concern about the fact that that proposal
> involves a protocol version bump. Have people not noticed? Does nobody
> care? To me, that thread reads like "I'm going to make a fire in the
> fireplace" but then there's a footnote that reads "by setting off a
> nuclear bomb" but we're only talking about how warm and cozy the fire
> will be. :-)
>
> I'm sure you're going to say "it's worth it" -- you wouldn't have
> written the patch otherwise -- but I wonder if it's going to feel
> worth it to everybody who has to deal with the downstream effects.

I didn't realize the issue with poolers is so widespread when I started
working on that patch this spring, and I gave up hoping to get it into
v17 when that was brought up.

Now, I think we should still do it, but it might not warrant changing
the default. Unfortunately that means that it will get very little
adoption. It will only be adopted as a side-effect of some other changes
that make people change the protocol_version setting. Or after a very
long transition period.

That said, I think we *should* change the default for the time being, so
that developers working on the bleeding edge and building from git get
some exposure to it. Hopefully that will nudge some of the poolers to
adopt NegotiateProtocolVersion sooner. But we revert the default to 3.0
before the v18 release.

--
Heikki Linnakangas
Neon (https://neon.tech)