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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: Noah Misch <noah(at)leadboat(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
Date: 2022-04-02 03:10:49
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: 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() This is something that needs to be
changed in the client code itself, and maybe the best fix is to
disable 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..

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2022-04-02 04:08:32 Re: Skipping logical replication transactions on subscriber side
Previous Message Michael Paquier 2022-04-02 02:58:55 Re: PostgreSQL shutdown modes