From: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: TAP tests - installcheck vs check |
Date: | 2017-04-24 02:57:13 |
Message-ID: | 8e93db2e-eb52-002c-0d8e-f97e46682813@2ndQuadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 04/23/2017 10:33 PM, Tom Lane wrote:
> 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.
>
>
That's actually the current meaning of installcheck w.r.t. TAP. See
Makefile.global.in. It's what we run (mostly) in the buildfarm for the
bin tests.
I agree entirely that it's confusing as heck. +1 for inventing a new name.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2017-04-24 03:18:48 | Re: pg_basebackup issue |
Previous Message | Tom Lane | 2017-04-24 02:53:15 | Re: [COMMITTERS] pgsql: Replication lag tracking for walsenders |