From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jacob Champion <jacob.champion@enterprisedb.com>
cc: Jelte Fennema-Nio <postgres@jeltef.nl>,
 pgsql-hackers@lists.postgresql.org,
        Andrew Dunstan <andrew@dunslane.net>
Subject: Re: pgsql: libpq: Grease the protocol by default
In-reply-to: 
 <CAOYmi+kC3AN0QJKT0OunHCmi4UU7-15eu7w-DY5ckOgHiQE1QA@mail.gmail.com>
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>
Comments: In-reply-to Jacob Champion <jacob.champion@enterprisedb.com>
	message dated "Mon, 23 Feb 2026 17:05:45 -0800"
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0"
Content-ID: <3864559.1771898929.0@sss.pgh.pa.us>
Content-Transfer-Encoding: 8bit
Date: Mon, 23 Feb 2026 21:08:56 -0500
Message-ID: <3864574.1771898936@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3864574.1771898936%40sss.pgh.pa.us>
Precedence: bulk

------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <3864559.1771898929.1@sss.pgh.pa.us>
Content-Transfer-Encoding: 8bit

Jacob Champion <jacob.champion@enterprisedb.com> writes:
> On Mon, Feb 23, 2026 at 4:45 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Also: I was initially baffled why you thought this needs
>> back-patching, but I guess you have one eye on packagers like
>> Debian who think they can make older versions use newer libpq.so.

> Right.

Actually, that is going to be harder than you thought, because libpq
before v18 will spit up on connection option "max_protocol_version".
This patch will not work as-is for back-patching unless we care to
also back-patch the addition of that option, which I'd be inclined
to resist.

Fortunately, we long ago had the foresight to invent PQlibVersion,
so you could make addition of the extra option conditional on
PQlibVersion(conn) >= 180000 in branches before 18.

> Hmmm, looks like the -dump1.log output is actually from *before*
> pg_upgrade actually runs:

Yeah, I came to the same conclusion.  I got a clean BF run using
your patch together with the attached patch for the BF client.
(In this patch, I did not worry about scenarios involving old
minor releases.  If Andrew is excited about that case he can
extend the version-comparison logic.)

			regards, tom lane


------- =_aaaaaaaaaa0
Content-Type: text/x-diff; name="cross-version.patch"; charset="us-ascii"
Content-ID: <3864559.1771898929.2@sss.pgh.pa.us>
Content-Description: cross-version.patch
Content-Transfer-Encoding: quoted-printable

--- PGBuild/Modules/TestUpgradeXversion.pm~	2025-11-25 07:47:25.000000000 =
-0500
+++ PGBuild/Modules/TestUpgradeXversion.pm	2026-02-23 20:57:31.640149574 -=
0500
@@ -483,9 +483,17 @@ sub test_upgrade    ## no critic (Subrou
 		$dump_opts .=3D ' --extra-float-digits=3D0';
 	}
 =

+	# with very old servers we must restrict the protocol version.
+	my $maxpversion =3D "";
+	if (   ($this_branch eq 'HEAD' || $this_branch gt 'REL_18_STABLE')
+		&& ($oversion ne 'HEAD' && $oversion le 'REL_9_2_STABLE'))
+	{
+		$maxpversion =3D '-d max_protocol_version=3D3.0';
+	}
+
 	# use the NEW pg_dumpall so we're comparing apples with apples.
 	setinstenv($self, "$installdir", $save_env);
-	system( qq{"$installdir/bin/pg_dumpall" $dump_opts -p $sport -f }
+	system( qq{"$installdir/bin/pg_dumpall" $dump_opts $maxpversion -p $spor=
t -f }
 		  . qq{"$upgrade_loc/origin-$oversion.sql" }
 		  . qq{> "$upgrade_loc/$oversion-dump1.log" 2>&1});
 	return if $?;

------- =_aaaaaaaaaa0--