Re: pgsql: libpq: Grease the protocol by default - Mailing list pgsql-hackers

From Jacob Champion
Subject Re: pgsql: libpq: Grease the protocol by default
Date
Msg-id CAOYmi+=96EGcQnY2w99yLeARHsbvgT_2Bv1hjXKUziykMzMhtA@mail.gmail.com
Whole thread
In response to Re: pgsql: libpq: Grease the protocol by default  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pgsql: libpq: Grease the protocol by default
List pgsql-hackers
On Mon, Feb 23, 2026 at 6:08 PM Tom Lane <tgl@sss.pgh.pa.us> 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".

Ha, right. Luckily the failure is very loud when testing :)

> 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.

Attached is a sample backport for REL_14_STABLE, using that strategy.
Tested with pg_upgrade 9.2-to-14, when linked against both 14.22 and
HEAD versions of libpq. I still need to run a sanity check with the
other 9.x lines to make sure I've selected the right cutoffs.

> 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.

Nice, thanks!

--Jacob

Attachment

pgsql-hackers by date:

Previous
From: Zsolt Parragi
Date:
Subject: Re: [PATCH] Simplify ExecWithoutOverlapsNotEmpty by removing unused parameter
Next
From: Nathan Bossart
Date:
Subject: Re: Make use of unvolatize() in vac_truncate_clog()