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

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Postgres hackers <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: 2021-10-03 03:32:36
Message-ID: 0f70fc0f-c51a-7a58-7e12-c702352eb076@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 10/2/21 5:03 PM, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)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.
>
>

The patch removes test.sh, so yes it would break.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-10-03 03:34:38 Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
Previous Message Marc Bachmann 2021-10-03 02:20:17 Re: BUG #16040: PL/PGSQL RETURN QUERY statement never uses a parallel plan