Re: libpq: Bump protocol version to version 3.2 at least until the first/second beta

On Fri, 30 Jan 2026 at 19:06, Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
> > A few thoughts on the implementation:
> > 1. If you like the randomization I did in my v5-0003
>
> From a quick skim, I do like it, thank you! My favorite part is the
> ability to send multiple grease parameters.

Great to hear.

> I think the minor version
> randomization is probably a weaker aspect of the patch, because the
> difference in difficulty between "==" and ">=" in a misbehaving server
> is much less than our new maintenance cost for randomizing it.

Yeah, agreed. I'm not sure how we could do any better though. I don't think

> > but don't want
> > to commit it yet.
>
> I won't focus on that just yet. I'd like opinions from other people,
> and at least one other maintainer, on a proposed
> `max_protocol_version=grease` for production use.

I didn't feel too strongly before that we should have this. But
recently I changed my opinion about that due to a recently reported
bug in the NegotatiateProtocolVersion of PgBouncer[1]. I had only
tested its implementation manually, but it turned out there was some
edge case where it didn't work correctly. I could now add a regression
test for that, because PgBouncer doesn't implement version 3.2 yet.
But once it does I won't be able to test its
NegotatioteProtocolVersion behaviour anymore (because it will not need
to negotiate). So I'd really like to have a
max_protocol_version=grease, so I can keep this test coverage.

I think similarly for Postgres it would be good to have coverage of
the NegotiateProtocolVersion logic of the server. And with
max_protocol_version=grease, we can actually do that.

[1]: https://github.com/pgbouncer/pgbouncer/issues/1459

> I think we can safely include the shorter one in a future suffix
> reservation, just by moving where the "wildcard" is, so I'm not too
> worried about that at the moment. But let me know if you feel strongly
> about it.

No, I don't feel strongly.

> > 2. It might be nice to also error duplicate keys in NegotiateProtocolVersion.
>
> I'm skeptical unless
> - we change the protocol itself to disallow duplicate parameters, in
> which case we don't have to grease it; or
> - you know of a specific reason a duplicate key in NPV could cause
> interoperability problems?

That's fair. Let's not do that then.