Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test
Date
Msg-id CAB7nPqTbevES3=Dqy2oBF03ccwRg+G=B--KRKn_kS2Bn5aQsKg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Sep 6, 2017 at 11:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
>> Peter Eisentraut wrote:
>>> We also need to have a plan for handling the build farm.  Maybe keep the
>>> vcregress.pl upgradecheck target as a thin wrapper for the time being?
>
>> The buildfarm already runs "make check" in src/bin/ when TAP tests are
>> enabled, which should be enough to trigger the rewritten test, no?
>
> I think Peter's on about the Windows case.  Not sure how that's handled,
> but it's not "make check".

For MSVC, one can use "vcregress.bat upgradecheck". So perhaps we
could keep upgradecheck for a short time but make it a noop instead
with this patch, and then remove it once buildfarm animals are
upgraded to a newer client version? I would prefer seeing a simple
removal of upgradecheck at the end, and put all TAP tests for binaries
under the bincheck path. This feels more natural.
-- 
Michael



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] Re: [COMMITTERS] pgsql: pg_rewind: Fix some problemswhen copying files >2GB.
Next
From: Amit Langote
Date:
Subject: Re: [HACKERS] Setting pd_lower in GIN metapage