MIME-Version: 1.0
References: <E1vub8B-000rlS-05@gemulon.postgresql.org>
 <CAOYmi+=4QhCjssfNEoZVK8LPtWxnfkwT5p-PAeoxtG9gpNjqOQ@mail.gmail.com>
 <3626145.1771885089@sss.pgh.pa.us>
 <CAOYmi+k8ENYkErqSEYEqW39YWPfe_ii7g5Acm1c9asNuRMriNg@mail.gmail.com>
 <3635497.1771889682@sss.pgh.pa.us>
 <CAOYmi+mtFBsB2zePSvbpa-2Zb-+V5bov_t2BzkGH7vfKX0ny_w@mail.gmail.com>
 <3797860.1771893905@sss.pgh.pa.us>
 <CAOYmi+kC3AN0QJKT0OunHCmi4UU7-15eu7w-DY5ckOgHiQE1QA@mail.gmail.com>
 <3864574.1771898936@sss.pgh.pa.us>
 <CAOYmi+=96EGcQnY2w99yLeARHsbvgT_2Bv1hjXKUziykMzMhtA@mail.gmail.com>
In-Reply-To: 
 <CAOYmi+=96EGcQnY2w99yLeARHsbvgT_2Bv1hjXKUziykMzMhtA@mail.gmail.com>
From: Jacob Champion <jacob.champion@enterprisedb.com>
Date: Tue, 24 Feb 2026 10:13:02 -0800
Message-ID: 
 <CAOYmi+=6AFrYm5LaPc=ECyLp2uh1-Y8xLA-dRBJE82JLRdiQ5g@mail.gmail.com>
Subject: Re: pgsql: libpq: Grease the protocol by default
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jelte Fennema-Nio <postgres@jeltef.nl>,
 pgsql-hackers@lists.postgresql.org,
	Andrew Dunstan <andrew@dunslane.net>,
 Nathan Bossart <nathandbossart@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAOYmi%2B%3D6AFrYm5LaPc%3DECyLp2uh1-Y8xLA-dRBJE82JLRdiQ5g%40mail.gmail.com>
Precedence: bulk

On Tue, Feb 24, 2026 at 9:18=E2=80=AFAM Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
> I still need to run a sanity check with the
> other 9.x lines to make sure I've selected the right cutoffs.

The cutoffs don't behave the way I thought they would.

Yesterday, I was about to complain that cluster.major_version was
poorly named -- why call it that if you have to pass it through
GET_MAJOR_VERSION() to get at what you want? -- but it does in fact
contain _only_ the major version information, because that's all that
PG_VERSION tells us. And unfortunately we don't save the result of the
version check for the old postgres binary anywhere.

So pg_upgrade will use max_protocol_version=3D3.0 with all servers v10
and below, in practice. There's nothing wrong with that behavior, but
I think I should switch to a simple `< 1100` check in the code to
avoid misleading people, unless anyone has a better way that won't
significantly increase the cost of the backport. (I could potentially
follow up with an improvement on HEAD, if the cost-benefit makes
sense, but I'm not sure it does.)

--Jacob