Re: Handling of REGRESS_OPTS in MSVC for regression tests - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Handling of REGRESS_OPTS in MSVC for regression tests
Date
Msg-id 20181127211049.GJ1716@paquier.xyz
Whole thread Raw
In response to Re: Handling of REGRESS_OPTS in MSVC for regression tests  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Handling of REGRESS_OPTS in MSVC for regression tests  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
List pgsql-hackers
On Tue, Nov 27, 2018 at 10:27:17AM +0900, Michael Paquier wrote:
> Okay, let's do so by supporting correctly NO_INSTALLCHECK.  My other
> refactoring work can also live with that.  Returning an empty list via
> fetchTests() and bypass a run if nothing is present looks fine to me.
> One extra thing is that modules/commit_ts and modules/test_rls_hooks are
> missing NO_INSTALLCHECK, so we would need to add that part to be
> completely correct.  I would also be inclined to back-patch both parts,
> however for my stuff I could live with this patch only on HEAD, and
> anybody willing to use installcheck on commit_ts and test_rls_hooks may
> be surprised to not be able to do that anymore after the minor release.
> It still looks incorrect to me though to be able to run installcheck on
> those modules though...
>
> Attached is a proposal of patch, which works as I would expect with
> modulescheck and contribcheck.  How does that look?

If possible, I would like to move on with this stuff.  To keep things
green in the buildfarm all the time, I would like to do that with two
independent steps:
1) Add NO_INSTALLCHECK to modules/commit_ts and modules/test_rls_hook.
2) Add support for NO_INSTALLCHECK in the MSVC scripts.

Are there any objections?  I could do a back-patch as well to keep
things consistent across branches if there are voices in favor of that,
but that's not necessary for the upcoming Makefile cleanup with the new
set of PGXS options.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: SSL tests failing with "ee key too small" error on Debian SID
Next
From: Michael Paquier
Date:
Subject: Re: Use durable_unlink for .ready and .done files for WAL segmentremoval