From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: TAP tests - installcheck vs check |
Date: | 2017-04-24 02:33:20 |
Message-ID: | 9787.1493001200@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-04-24 02:40:55 | Re: logical replication and PANIC during shutdown checkpoint in publisher |
Previous Message | Andres Freund | 2017-04-24 02:33:05 | Re: walsender & parallelism |