Re: can we add subscription TAP test option "vcregress subscriptioncheck" for MSVC builds?

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: can we add subscription TAP test option "vcregress subscriptioncheck" for MSVC builds?
Date: 2021-10-06 02:22:37
Message-ID: YV0IbQp4fMRZKEf2@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 06, 2021 at 07:19:04AM +0530, Bharath Rupireddy wrote:
> I was thinking of the same. +1 for "vcregress check-world" which is
> more in sync with it's peer "make check-world" instead of "vcregress
> all-taptest". I'm not sure whether we can also have "vcregress
> installcheck-world" as well.

check-world, if it spins new instances for each contrib/ test, would
be infinitely slower than installcheck-world. I recall that's why
Andrew has been doing an installcheck for contribcheck to minimize the
load. If you run the TAP tests, perhaps you don't really care anyway,
but I think that there is a case for making this set of targets run as
fast as we can, if we can, when TAP is disabled.

> Having said that, with these new options, are we going to have only below?
>
> vcregress check
> vcregress installcheck
> vcregress check-world
> vcregress installcheck-world (?)
>
> And remove others?

My take is that there is value for both installcheck-world and
check-world, depending on if we want to test on an installed instance
or not. For CIs, check-world makes things simpler perhaps?

> vcregress plcheck
> vcregress contribcheck
> vcregress modulescheck
> vcregress ecpgcheck
> vcregress isolationcheck
> vcregress bincheck
> vcregress recoverycheck
> vcregress upgradecheck

I don't really see why we should do that, the code paths are the same
and the sub-routines would still be around, but don't cost much in
maintenance.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2021-10-06 02:52:53 Re: Added schema level support for publication.
Previous Message Greg Nancarrow 2021-10-06 02:18:39 Re: Skipping logical replication transactions on subscriber side