On 05/08/2011 07:35 PM, Tom Lane wrote:
> I believe that the "make check" target in src/test/isolation is
> fundamentally unportable, as is illustrated by the fact that buildfarm
> member coypu is currently choking on it. The reason is that the
> pg_isolation_regress program depends on libpq, and in particular it
> depends on having an *installed* libpq. Anyplace where it appears to
> work, it's because you already installed Postgres, or at least libpq.
darn, you're right.
> Apparently coypu is the only buildfarm member that hasn't got a
> reasonably recent libpq already installed in system directories; or
> maybe it's just the first such that's tried to run the isolation-test
> script step.
Most aren't running the test because they aren't updated yet. There are
six machines running the tests:
pgbfprod=# select distinct sysname from build_status_log where log_stage ~ 'isolation' and snapshot > now() -
interval'2 months'; sysname --------- anchovy coypu crake bobcat chough kite
chough is doing the wrong thing anyway, because I got distracted and
forgot to fill in the MSVC piece of the puzzle.
> While we could maybe hack this to the point where it works (on some
> platforms) by dynamically linking libpq from the source tree, I don't
> think it's worth the trouble.
>
> Recommendations:
>
> 1. Modify the buildfarm script to run "make installcheck" in the
> isolation-test step, and of course move that to after doing the install
> step.
working on that.
I have pushed a quick fix disabling the test for now until I come up
with proper coding for this tomorrow. See
<https://github.com/PGBuildFarm/client-code/commit/bb1d2f972205d0a8f438bfde86a0fc99ffdeb24a>
> 2. Get rid of the "check" target in src/test/isolation/Makefile.
> We don't need to be dealing with bug reports from people who try to
> use it and get either a link failure (easily diagnosed) or a libpq
> version compatibility problem (not so easily diagnosed).
>
>
+1.
cheers
andrew
