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
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 |