Horton

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
Cc: Andres Freund <andres@anarazel.de>, Thomas Munro <thomas.munro@gmail.com>, Noah Misch <noah@leadboat.com>, Julien Rouhaud <rjuju123@gmail.com>, Andrew Dunstan <andrew@dunslane.net>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-03-31T05:00:14Z
Lists: pgsql-hackers 
Michael Paquier <michael@paquier.xyz> writes:
> So, any particular feelings about this patch?  This has been around
> for a couple of months/years now, so it could be a good time to do the
> switch now rather than wait an extra year, or even the beginning of
> the next release cycle.  And the buildfarm is already able to handle
> that in its code based on the last release, by skipping the upgrade
> check if it finds a pg_upgrade/t/ subdirectory.

There's still about a third of the buildfarm running older
client releases --- I count

      2 REL_8
      2 REL_10
     13 REL_11
      6 REL_12
     16 REL_13.1
     89 REL_14

How well does this patch work with pre-14 buildfarm clients?

			regards, tom lane

Commits

  1. Improve and fix some issues in the TAP tests of pg_upgrade

  2. Fix several issues with the TAP tests of pg_upgrade

  3. Make upgradecheck a no-op in MSVC's vcregress.pl

  4. Switch the regression tests of pg_upgrade to use TAP tests

  5. Fix check for PGHOST[ADDR] in pg_upgrade with Windows and temporary paths

  6. Remove REGRESS_OUTPUTDIR environment variable.

  7. Add PostgreSQL::Test::Cluster::config_data()