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

From: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
To: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: libpq: Bump protocol version to version 3.2 at least until the first/second beta
Date: 2026-02-09 23:55:56
Message-ID: CAGECzQTWj+D=tNopj6qMzpP6g46P95Wd6LSrFjZEfB20tzQU-g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Feb 6, 2026, 23:39 Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
wrote:

>
> Committed that way, along with v6-0002.
>
Nice!

That just leaves the last TODO, which is guiding users towards a
> resolution. First attempt at that is attached as v7:
> - v7-0001 is the same as v6-0003 with an updated commit message.
> - v7-0002 is a squash! commit that prints a quick explanation and a
> link to our documentation for all grease-related libpq errors.
>
> At the moment, that link is
>
> https://www.postgresql.org/docs/devel/libpq-connect.html#LIBPQ-CONNECT-MAX-PROTOCOL-VERSION
> which will contain a <note> on grease when this is committed.
>
> I'd still prefer that this link go to a wiki page, but in case I can't
> get agreement on that, or there's some technical reason why protecting
> the page wouldn't work out the way I'd hoped, or it just takes a long
> time, this seems better than nothing. Switching out the URL in a later
> commit shouldn't be an issue.
>
> WDYT?
>

Looks like a good improvement. As said before I'm fine with either location
for the URL.

>
I'm wondering if we should be a bit more liberal in showing this error
explanation, since I expect most servers to throw an error rather than send
an incorrect negotiation. e.g. We could report it on hard connection
closures. Or if there is "3.9999" or "version" or "_pq_" in the error
message. (the message should then be "this could indicate a bug in..."
because we're not fully certain)

>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jonathan S. Katz 2026-02-10 00:01:56 2026-02-12 release announcement draft
Previous Message Michael Paquier 2026-02-09 23:37:10 Re: recovery.signal not cleaned up when both signal files are present