Обсуждение: libpq: Bump protocol version to version 3.2 at least until the first/second beta

The main reason that libpq does not request protocol version 3.2 by
default is because other proxy/server implementations don't implement
the negotiation. This is a bit of a chicken and egg problem: We don't
bump the default version that libpq asks, but proxies will only
implement version negotation when their users run into issues. So I'm
proposing that we bump the default protocol version that libpq requests
on the master branch, so that users running the latest master against a
proxy that does not support the version negototian will be notified.
They can then push the author of the proxy to implement the
NegototiateProtocolVersion message.

Depending on how this works in practice we'll likely still want to
revert this change before we actually release PG19. If we do that before
19beta1 we still have roughly half a year where people will test the
ecosystem. I'd even suggest that we only revert before 19beta2, so that
people testing beta1 will also be testing the ecosystem for version
negotiation issues. In any case, the sooner we commit this the more
testing we get,

Note that users still have a way out to connect to the server by
manually setting max_protocol_version=3.0 in the connection string.

On Thu Oct 23, 2025 at 3:56 PM CEST, Jelte Fennema-Nio wrote:
> So I'm
> proposing that we bump the default protocol version that libpq requests
> on the master branch, so that users running the latest master against a
> proxy that does not support the version negototian will be notified.

Rebased to resolve conflict

On Thu, Oct 23, 2025 at 6:56 AM Jelte Fennema-Nio <me@jeltef.nl> wrote:
> Depending on how this works in practice we'll likely still want to
> revert this change before we actually release PG19. If we do that before
> 19beta1 we still have roughly half a year where people will test the
> ecosystem.

I think the whole plan probably belongs in the user documentation.
Even if no one were to read it, I still wouldn't want the declaration
that "we default to the latest" to be mixed into the growing search
engine slop pile.

Is there an even stronger way for us to grease this? For example,
could we agree that no one will ever implement 0003.7FFF and push that
during the beta, failing if anyone gives us an unsupported version?

--Jacob

On Fri, 31 Oct 2025 at 17:24, Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
> I still wouldn't want the declaration
> that "we default to the latest" to be mixed into the growing search
> engine slop pile.

Fair enough (although the intent is to get to that state at some point).


> Is there an even stronger way for us to grease this? For example,
> could we agree that no one will ever implement 0003.7FFF and push that
> during the beta, failing if anyone gives us an unsupported version?

I quite like that idea! Although maybe not 7FFF, but 270F so that
PQfullProtocolVersion returns 39999. And I think it'd be good to also
add a protocol option, like _pq_.test_protocol_breakage and fail the
connection attempt client side if that does not get returned back as
unsupported. I'll try to update this patch to do that in the coming days.

On Fri, Oct 31, 2025 at 2:56 PM Jelte Fennema-Nio <me@jeltef.nl> wrote:
> I quite like that idea! Although maybe not 7FFF, but 270F so that
> PQfullProtocolVersion returns 39999.

+1

> And I think it'd be good to also
> add a protocol option, like _pq_.test_protocol_breakage and fail the
> connection attempt client side if that does not get returned back as
> unsupported.

Yeah, I feel better signing on to a plan like this if we think the
breakage is likely to lead to a comprehensive fix for
NegotiateProtocolVersion (as opposed to "we greased this thing in 2025
and now this thing in 2026 and now...").

Thanks,
--Jacob

On Fri Oct 31, 2025 at 11:52 PM CET, Jacob Champion wrote:
> On Fri, Oct 31, 2025 at 2:56 PM Jelte Fennema-Nio <me@jeltef.nl> wrote:
> Yeah, I feel better signing on to a plan like this if we think the
> breakage is likely to lead to a comprehensive fix for
> NegotiateProtocolVersion (as opposed to "we greased this thing in 2025
> and now this thing in 2026 and now...").

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).

Hi,

On 2025-11-03 15:46:10 +0100, Jelte Fennema-Nio wrote:
> From 31851ddff8cb40f732aac0bfac364da61ed9fa30 Mon Sep 17 00:00:00 2001
> From: Jelte Fennema-Nio <postgres@jeltef.nl>
> Date: Thu, 23 Oct 2025 15:08:52 +0200
> Subject: [PATCH v3 2/2] libpq: Request protocol version 3.9999 to GREASE the
>  ecosystem
> 
> The main reason that libpq does not request protocol version 3.2 by
> default is because other proxy/server implementations don't implement
> the negotiation. This is a bit of a chicken and egg problem: We don't
> bump the default version that libpq asks, but proxies will only
> implement version negotiation when their users run into issues.

> This patch defines 3.999 as an explicitly unsupported protocol version
> number and _pq_.test_protocol_negotiation as an explicitly unsupported
> protocol extension. It also starts requesting that version and protocol
> extension by default. This change to the default will be reverted before
> we release PG19 release candidates (when exactly to revert before that
> time is TBD). The intent is to stress test the ecosystem for
> servers/middleware that don't support protocol version negotiation, so
> that those servers/middleware can implement the negotiation. This is
> similar to the GREASE[1] mechanism that TLS has.
> 
> It's still possible for users to connect to servers that don't support
> protocol negotiation by using max_protocol_version=3.0 in their
> connection string. Only the default connection behaviour is impacted.
> 
> [1]: https://www.rfc-editor.org/rfc/rfc8701.html

Won't this mean that it'll be harder to performance comparisons between the
in-development version and other versions? Because there will be negotiation
before we branch of 19, but not after and not in release branches?

Greetings,

Andres Freund

On Mon, 3 Nov 2025 at 15:59, Andres Freund <andres@anarazel.de> wrote:
> Won't this mean that it'll be harder to performance comparisons between the
> in-development version and other versions? Because there will be negotiation
> before we branch of 19, but not after and not in release branches?

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.