Re: [HACKERS] TAP tests - installcheck vs check - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] TAP tests - installcheck vs check
Date
Msg-id 9787.1493001200@sss.pgh.pa.us
Whole thread Raw
In response to [HACKERS] TAP tests - installcheck vs check  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Responses Re: [HACKERS] TAP tests - installcheck vs check  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
List pgsql-hackers
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> AFAICT, unlike the pg_regress checks, which in the installcheck case run
> against a running instance of postgres, for TAP tests the only
> difference is that that for the check case a temp install is done,
> possibly with some extra contrib modules. Is that correct? If is is, why
> aren't we providing an installcheck target for tests like recover. In at
> least one case (buildfarmn jacana) installs are quite expensive (2 or 3
> minutes) and if they are pointless as seems to be the case here why
> can't we just avoid them?

A lot of those test cases involve setting non-default configuration
parameters and/or stopping/starting the postmaster.  So I can't see how
we would run them against a pre-existing live cluster, which is the usual
meaning of "make installcheck".

I think what you're imagining is skipping redundant builds of the
"tmp_install" tree by using an installation tree with a temporary $PGDATA
directory.  That seems like a fine idea, but we need another word for it.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] walsender & parallelism
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] logical replication and PANIC during shutdowncheckpoint in publisher