On Sun, Apr 23, 2017 at 10:57 PM, Andrew Dunstan <andrew.duns...@2ndquadrant.com> wrote: > On 04/23/2017 10:33 PM, Tom Lane wrote: >> Andrew Dunstan <andrew.duns...@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. > > 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.
Yeah. I would have expected installcheck to just skip any tests that don't make sense against an already-installed cluster. I would not expect it to run those tests against some cluster other than the installed cluster. That seems super-weird. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
