From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Christoph Berg <christoph(dot)berg(at)credativ(dot)de>, Bruce Momjian <bruce(at)momjian(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Useless "Replica Identity: NOTHING" noise from psql \d |
Date: | 2014-03-27 17:09:36 |
Message-ID: | 7249.1395940176@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> Note that "make check" in contrib is substantially slower than "make
> installcheck" --- it creates a temporary installation for each contrib
> module. If we make buildfarm run installcheck for all modules, that
> might be a problem for some animals. Would it be possible to have a
> target that runs "make installcheck" for most modules and "make check"
> only for those that need the separate installation? Maybe we can have a
> file listing modules that don't support installcheck, for instance, and
> then use $(filter) and $(filter-out) to produce appropriate "$(MAKE) -C"
> loops.
This seems like a good idea to me; the slower animals will be putting lots
of cycles into pretty-much-useless "make check" builds if we don't.
Rather than a separate file, though, I think a distinct target in
contrib/Makefile would be the best mechanism for keeping the list of
modules that lack installcheck support. Perhaps "make special-check"
or some name along that line?
> Also, there's the vcregress.pl business. The way it essentially
> duplicates pg_upgrade/test.sh is rather messy; and now that
> test_decoding also needs similar treatment, it's not looking so good.
> Should we consider redoing that stuff in a way that allows both MSVC and
> make-based systems to run those tests?
Agreed, but I'm not volunteering to fix that one ;-)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Meskes | 2014-03-27 17:35:26 | Re: using arrays within structure in ECPG |
Previous Message | Christoph Berg | 2014-03-27 17:03:24 | Re: [patch] Adding EXTRA_REGRESS_OPTS to all pg_regress invocations |