Re: multi-install PostgresNode fails with older postgres versions - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: multi-install PostgresNode fails with older postgres versions
Date
Msg-id YH14QVeGXy3AiEfe@paquier.xyz
Whole thread Raw
In response to Re: multi-install PostgresNode fails with older postgres versions  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: multi-install PostgresNode fails with older postgres versions  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
On Mon, Apr 19, 2021 at 08:11:01AM -0400, Andrew Dunstan wrote:
> As far as I know, without any compatibility changes the module is fully
> compatible with releases 13 and 12, and with releases 11 and 10 so long
> as you don't want a standby, and with releases 9.6 and 9.5 if you also
> don't want a backup. That makes it suitable for a lot of testing without
> any attempt at version compatibility.
>
> We can revisit compatibility further in the next release.

Agreed, and I am not convinced that there is any strong need for any
of that in the close future either, as long as there are no
ground-breaking compatibility changes.

How far does the buildfarm test pg_upgrade?  One thing that I
personally care about here is the possibility to make pg_upgrade's
test.sh become a TAP test.  However, I am also pretty sure that we
could apply some local changes to the TAP test of pg_upgrade itself to
not require any wide changes to PostgresNode.pm either to make the
central logic as simple as possible with all the stable branches still
supported or even older ones.  Having compatibility for free down to
12 is nice enough IMO for most of the core logic, and pg_upgrade would
also work just fine down to 9.5 without any extra changes because we
don't care there about standbys or backups.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Forget close an open relation in ReorderBufferProcessTXN()
Next
From: bchen90
Date:
Subject: Do we need to update copyright for PG11 branch