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

From Nathan Bossart
Subject Re: pgsql: libpq: Grease the protocol by default
Date
Msg-id aZ3PJG-tLJomZfck@nathan
Whole thread Raw
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 06:34:42PM -0500, Tom Lane wrote:
> Jacob Champion <jacob.champion@enterprisedb.com> writes:
>> On Mon, Feb 23, 2026 at 2:18 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Either that or we decide that it's time to throw 9.2 support
>>> overboard (looks like 9.3 and up are fine).
> 
>> Well, while I was hacking on a patch I realized that 9.3 (all the way
>> up to 10) is only okay if you're running a sufficiently patched
>> version. PG11 is the first to support negotiation for the whole
>> release line.
> 
> Hmm ... and of course the whole point of this exercise is to be sure
> we can pg_upgrade from those out-of-support versions.

I discussed this a bit on the hacking Discord last year, but IMHO we're
reaching a good point to bump up pg_upgrade's oldest supported major
version.  I'll probably push to bump it to v10 for the v20 release so that
we can remove many of the version-specific hacks we've built up over the
years.  Not to mention that the cross-version tests (the "export
oldinstall" ones described in pg_upgrade's TESTING file, not the buildfarm
ones) don't seem to work past v10 or so because they use various options
that didn't exist or have since been renamed.

Granted, this probably doesn't help the present issue...

-- 
nathan



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Add errdetail() with PID and UID about source of termination signal
Next
From: Tom Lane
Date:
Subject: Warning-suppression fixes we ought to back-patch