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

From Andrew Dunstan
Subject Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
Date
Msg-id 0f70fc0f-c51a-7a58-7e12-c702352eb076@dunslane.net
Whole thread Raw
In response to Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 10/2/21 5:03 PM, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.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




pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Enabling deduplication with system catalog indexes
Next
From: Tom Lane
Date:
Subject: Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set