On 2026-02-24 Tu 10:55 AM, Andrew Dunstan wrote:
>
>
> On 2026-02-23 Mo 9:08 PM, Tom Lane wrote:
>> 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.)
>>
>>
>
>
> I am not worried about old minor releases. I am currently testing a
> patch with similar intent to yours.
>
>
Here's what worked for me, even before Jacob's patch of 15 minutes or so
ago.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
