Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
Date
Msg-id Yke+udObixJVpDDx@paquier.xyz
Whole thread Raw
In response to Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set  (Justin Pryzby <pryzby@telsasoft.com>)
List pgsql-hackers
On Fri, Apr 01, 2022 at 08:34:34AM -0500, Justin Pryzby wrote:
> If you do that, should also remove upgradecheck from .cirrus.yaml, which
> currently runs the upgradecheck target.

Indeed.  It makes no sense to keep that.  I have removed this part and
applied the patch, after one extra run through the CI.

> An alternative to your patch to have the buildfarm client avoid calling
> upgradecheck if tap tests are disabled.  Under your patch, upgrade check is a
> NOP, so it should stop calling upgradecheck anyway.  So maybe this is a better
> option ?

Yeah, there is an extra issue with the buildfarm client here.  The
animals that have TAP enabled are now running the tests of pg_upgrade
twice: once per the optional module TestUpgrade and once in
run_bin_tests()@run_build.pl.  This is something that needs to be
changed in the client code itself, and maybe the best fix is to
disable TestUpgrade.pm when running with v15~ or a newer version.  A
fix with this approach would become much easier once REL_15_STABLE is
created, though.  I am pretty sure that it should also be possible to
change the list of optional modules depending on the branch running,
but I have not dug into that..
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: PostgreSQL shutdown modes
Next
From: Amit Kapila
Date:
Subject: Re: Skipping logical replication transactions on subscriber side