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

From Andres Freund
Subject Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
Date
Msg-id 20211214061449.ynrygtcddn3ujunn@alap3.anarazel.de
Whole thread Raw
In response to Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On 2021-12-14 14:31:24 +0900, Michael Paquier wrote:
> On Mon, Dec 13, 2021 at 06:08:24PM -0800, Andres Freund wrote:
> > Seems like we might get away with making make -C contrib/pg_upgrade check and
> > vcregress.pl upgradecheck do nothing?
> 
> You mean #contrib/#src/bin/# here, right?  I don't think that we have
> any need to have "make -C" do nothing.  For vcregress.pl, we should
> IMO just remove upgradecheck.

Tom's point was that the buildfarm scripts do
    if ($self->{bfconf}->{using_msvc})
        @checklog = run_log("perl vcregress.pl upgradecheck");
    else
              "cd $self->{pgsql}/src/bin/pg_upgrade && $make $instflags check";

if we don't want to break every buildfarm member that has TestUpgrade enabled
the moment this is committed, we need to have a backward compat path.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: Skipping logical replication transactions on subscriber side
Next
From: Jeff Davis
Date:
Subject: Re: Commitfest 2021-11 Patch Triage - Part 3