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

On Mon, Nov 3, 2025 at 7:42 AM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
> The negotiation does not require a separate roundtrip, only a tiny
> additional message sent by the server. So I'm not worried about that
> resulting in a measurable perf change. And even if there is one in
> some super extreme benchmark, then you can still set
> max_protocol_version=3.0 to revert to the regular behaviour.

Andres, should I take from the silence that you're satisfied with that?

On Mon, Nov 3, 2025 at 6:46 AM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
> Attached is a new version of the patch that reserves version 3.9999 and
> _pq_.test_protocol_negotiation and starts requesting those by default
> (which we should revert before at least PG19rc1 and possibly earlier).

Partial review follows, in a v4 squash! set, as requested on the Discord :)

v4-0001 and 0002 should be identical to v3, modulo any rebased diff context.

v4-0003: I was initially confused about the need to change the
max_protocol_version_index logic in v3-0001 (it's because empty
parameter values are ignored by PQconnectdbParams). Then I decided
that if we have to maintain the logic to overwrite
max_protocol_version in-place, we might as well always use it. v4-0003
does that and adds some explanation.

v4-0004 does a cosmetic move of the PG_PROTOCOL_GREASE macro now that
we have a section for it.

v4-0005 is a temporary distraction to move protocol version 3.1 into
the same place. If people don't like it I'm happy to drop it for now
(it may deserve at least some bikeshedding on the macro name, since
it's part of a public header).

= Additional Thoughts =

I want to more clearly decouple ourselves from TLS's GREASE in the
documentation and comments. We aren't "Generating Random Extensions"
(we _could_, but that takes a lot more thought), nor are we telling
OpenSSL to enable GREASE for our TLS connections. It's fine if we want
to gesture in that direction as broader context, but I don't want to
cause user confusion. I'll work on some proposed changes for that.

I'd like reserve a (protected?) wiki page, or something of the sort,
that we can point people to directly if they hit any grease failures.
"Server screwed up" is probably not enough context for a typical user
to know what to do next.

I will also work on splitting 0002 into revertable and not-revertable
halves. The grease constant probably needs to remain documented and
reserved even if it doesn't do anything for 19.0.

Finally: is there any appetite for retaining the ability to grease
connections as production functionality, e.g. via
`max_protocol_version=grease`? Personally I think it'd be nice, but
it's not a trivial amount of extra work. We'd have to handle the case
where a future server responds with a legitimate minor version that's
newer than what our version of libpq supports. And I think we'd want a
production-grade version of this to add some randomization tricks, to
discourage people from keying on grease constants.

Thanks,
--Jacob