Re: Useless "Replica Identity: NOTHING" noise from psql \d

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

In response to

Responses

Browse pgsql-hackers by date

  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