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

On Sat, 31 Jan 2026 at 12:06, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> wrote:
> > 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

I realized I hadn't finished writing down my thoughts here. The reason
I think we cannot do better is because even if we request some non
consecutive versions, there are essentially three options for the
minimum version those non consecutive ones:
1. Either we request a very high one (e.g. 3.1000) that will mean your
>= could simply be changed do 3.1000. So there's no benefit.
2. We request a very low one, e.g. 3.3. That means the next actual
version would need to be 3.4. At that point a new libpq with
max_protocol_version=grease would never want to request that grease
version anymore because it would force a downgrade to below its
maximum supported version. We could ofcourse reserve the next one.
Doing so would basically mean that we would reserve all uneven minor
protocol version numbers. That seems a bit silly.
3. Somewhere low but still in the middle, e.g. 3.15. This would
postpone the problem of 2, but would not eliminate it.

All in all, I don't really think it's wort the complexity. It seems
unlikely to me that a server authors will write "version == 30009999"
instead of "version > 30000000" or "version > MAX_SUPPORTED_VERSION"
when checking when to send the NegotiateProtocolVersion message.