Horton

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

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, 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-31T07:56:36Z
Lists: pgsql-hackers 
On Wed, Mar 30, 2022 at 10:36:16PM -0700, Andres Freund wrote:
> On 2022-03-31 01:00:14 -0400, Tom Lane wrote:
> > How well does this patch work with pre-14 buildfarm clients?
> 
> Looks to me like it'll just run the test twice, once via TestUpgrade, once via
> taptest. It's possible that there could be trouble somehow due to duplicated
> log files or something?

Hmm.  TestUpgrade.pm also uses tmp_check/, and the TAP tests would
remove this path before running.  Still, all the contents of the logs
would be printed out before moving to the next tests at the end of
check-pg_upgrade.  It does not seem like this double run is going to
be an issue on this side. 
--
Michael

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