Content-Type: multipart/alternative;
 boundary="------------ooOn89b5bugILcwSLfwtZsH7"
Message-ID: <ebe65134-a062-4e85-b7be-387f29ea3836@dunslane.net>
Date: Tue, 24 Feb 2026 10:55:20 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: pgsql: libpq: Grease the protocol by default
To: Tom Lane <tgl@sss.pgh.pa.us>,
 Jacob Champion <jacob.champion@enterprisedb.com>
Cc: Jelte Fennema-Nio <postgres@jeltef.nl>, pgsql-hackers@lists.postgresql.org
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>
From: Andrew Dunstan <andrew@dunslane.net>
Content-Language: en-US
Autocrypt: addr=andrew@dunslane.net; keydata=
 xsBNBE7KWFkBCAClridxur2AIc7eW2AR7izbfp3EnNefie2HbLF0izW5Ik5UjX2HBXBx4syI
 gY6b0ugohXrr274+baoAlvSbq6cAoQuEVrk5IZFzt20b1Xkx65FwGSEj526yiKLocqkJceSq
 Xr9xcA5SGY+FZv441chh5SU92v4q6z+6LPpoHOh97ptAVXZYNTtU0LevyvD5lja0TzbvJm6C
 eFXitJfnm1pLEr0DGJCR/iUOl/N62Kh4855zZC7NHIjQHPOvV5Stz/l5ilDhvGVk+xkXFPys
 SjZoUr1rXhYLpiyi5sR0X9FHXT0KnGuz1F5ERO7ZTLSSQ6fJwPj6gOk9K+vvoKvoeql5ABEB
 AAHNJEFuZHJldyBEdW5zdGFuIDxhbmRyZXdAZHVuc2xhbmUubmV0PsLAlwQTAQgAQQIbAwIX
 gAIZAQULCQgHAwUVCgkICwUWAgMBAAIeBRYhBOQ+WEYd/Hy/RGkVpZn6f8tZ/DuBBQJoGNGd
 BQkdEO8nAAoJEJn6f8tZ/DuBq74H/jkTR4Zi3stbw+xC7v2u3QozssK7MYPL2AsVfh7OealS
 h182fiWXpfvmmAB7WUHbhk9GC2RAOnHI/2d2jgKaMLAHsGYOT0YopTVIwRY43fCw/mK67yxc
 wmDcX+zyKfLaivNbf5A7QPLNwda98bEAMSJ8Sn652Uc6cA8t3uKGsVzbRBQOoYzjgvBCfSrE
 9ql3PDNg0l4BfAqabd2f70ZUm9VAMEPrgv/v2xI7M2XiL4g5BVmqLCOwxLM8RMCotCuoweUr
 VO43DeBCIDwLxotMJKvGWDjBzQYlU1NPUAtNcz/gN9ITUe1VUGjyvGj4u1lxBOcQQUw7l1+T
 5moZ4iZxXzvOwE0ETspYWQEIANGc4zQULOxhbqO2dyD51YhqCNRmm9oKWaqf+wmW4tpDe/VV
 cxAnNizd4LWCHfzpb5cHAtGkOPePMfzWVf6nvdF7d3eglbtf59+zG7O7llV0xSSoFiieQBsr
 GvqDInXYX/4mRRXMtyhM353/tixC9RWLs1oofyYmCPPXXY7h9R7en3B8BoVrRFcdzlIY/NFN
 hFGW/9dkEiGjgna2Rk6e15kln4ZvFBWUg23p93w/pqXcxY6+k/8TEk+C4R+M6w7o2PLGOjdZ
 +kPiUcw5H85zf/yZJwQXzisXaNduwWB6Vads9YC9dj6kPR1c4VGRqAaYL++LAEOqrlvm2Tvq
 QqZRtnEAEQEAAcLAfAQYAQgAJgIbDBYhBOQ+WEYd/Hy/RGkVpZn6f8tZ/DuBBQJoGNI2BQkd
 EODdAAoJEJn6f8tZ/DuBfw0IAKTsfD40teP/pp+bsLLMSxPXUYrrprTj7WFB5v61p6dkpSr/
 qXmMlyahdxQFaPmfVgVirB1Vk/kHiWNnnGjfUV9nB2Zg9LI0Xb9/ts3LsUiRWXzG3tkMY6XL
 vsVOxW4XFRND9l2q+WW93aZ1DZl+fqWfYgMvsusFRhmGFOKTRfKPta2Pkv+AhA24N4+PrR5p
 bU4k2MO8PAGiK8eaYKGFG1bHKuAvoDoF7WXJ3FHxuWqLnKEt4dfOLm5pAe3zq1Lt6q8azT9i
 QWGpSAK5vQUWQHBHpiDjdPeqKZ6HiAXIIKfSmb+jrvXBqoP+D6/K7rUjG2aXiRtTIAXms9sm
 VRu7cmw=
In-Reply-To: <3864574.1771898936@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/ebe65134-a062-4e85-b7be-387f29ea3836%40dunslane.net>
Precedence: bulk

This is a multi-part message in MIME format.
--------------ooOn89b5bugILcwSLfwtZsH7
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


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.


cheers


andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com

--------------ooOn89b5bugILcwSLfwtZsH7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 2026-02-23 Mo 9:08 PM, Tom Lane
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:3864574.1771898936@sss.pgh.pa.us">
      <pre wrap="" class="moz-quote-pre">Jacob Champion <a class="moz-txt-link-rfc2396E" href="mailto:jacob.champion@enterprisedb.com">&lt;jacob.champion@enterprisedb.com&gt;</a> writes:
</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">On Mon, Feb 23, 2026 at 4:45 PM Tom Lane <a class="moz-txt-link-rfc2396E" href="mailto:tgl@sss.pgh.pa.us">&lt;tgl@sss.pgh.pa.us&gt;</a> wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="" class="moz-quote-pre">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.
</pre>
        </blockquote>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">Right.
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
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) &gt;= 180000 in branches before 18.

</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">Hmmm, looks like the -dump1.log output is actually from *before*
pg_upgrade actually runs:
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
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.)

			</pre>
    </blockquote>
    <p><br>
    </p>
    <p>I am not worried about old minor releases. I am currently testing
      a patch with similar intent to yours.</p>
    <p><br>
    </p>
    <p>cheers</p>
    <p><br>
    </p>
    <p>andrew<span style="white-space: pre-wrap">
</span></p>
    <pre class="moz-signature"
    signature-switch-id="d0437855-2267-4610-80b3-83167ec45b0b" cols="72">--
Andrew Dunstan
EDB: <a class="moz-txt-link-freetext" href="https://www.enterprisedb.com">https://www.enterprisedb.com</a>
</pre>
  </body>
</html>

--------------ooOn89b5bugILcwSLfwtZsH7--