On 4/19/21 8:32 AM, Michael Paquier wrote: > 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.
The buildfarm tests self-targetted pg_upgrade by calling the builtin tests (make check / vcregress.pl upgradecheck). However, for cross version testing the regime is quite different. The cross version module doesn't ever construct a repo. Rather, it tries to upgrade a repo saved from a prior run. So all it does is some adjustments for things that have changed between releases and then calls pg_upgrade. See <https://github.com/PGBuildFarm/client-code/blob/master/PGBuild/Modules/TestUpgradeXversion.pm> Note that we currently test upgrades down to 9.2 on crake. However, now I have some working binaries for really old releases I might extend that all the way back to 8.4 at some stage. pg_upgrade and pg_dump/pg_restore testing are the major use cases I can see for backwards compatibility - pg_dump is still supposed to be able to go back into the dim dark ages, which is why I built the old binaries all the way back to 7.2. .... It's just occurred to me that a much nicer way of doing this PostgresNode stuff would be to have a function that instead of appending to the config file would adjust it. Then we wouldn't need all those little settings functions to be overridden - the subclasses could just post-process theĀ config files. I'm going to try that and see what I can come up with. I think it will look heaps nicer. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com -- -- Andrew Dunstan EDB: https://www.enterprisedb.com