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: Andrew Dunstan <andrew@dunslane.net>
Cc: Michael Paquier <michael@paquier.xyz>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-10-02T21:03:33Z
Lists: pgsql-hackers 
Andrew Dunstan <andrew@dunslane.net> writes:
> I haven't looked at the patch closely yet, but from a buildfarm POV I
> think the only thing that needs to be done is to inhibit the buildfarm
> client module if the TAP tests are present. The buildfarm code that runs
> TAP tests should automatically detect and run the new test.

> I've just counted and there are 116 animals reporting check-pg_upgrade,
> so we'd better put that out pronto. It's a little early but I'll try to
> push out a release containing code for it on Monday or Tuesday (it's a
> one line addition).

IIUC, the only problem for a non-updated animal would be that it'd
run the test twice?  Or would it actually fail?  If the latter,
we'd need to sit on the patch rather longer.

			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()