Re: TAP test breakage on MacOS X - Mailing list pgsql-hackers

From Tom Lane
Subject Re: TAP test breakage on MacOS X
Date
Msg-id 20973.1414681986@sss.pgh.pa.us
Whole thread Raw
In response to Re: TAP test breakage on MacOS X  (Noah Misch <noah@leadboat.com>)
Responses Re: TAP test breakage on MacOS X
Re: TAP test breakage on MacOS X
List pgsql-hackers
Noah Misch <noah@leadboat.com> writes:
> Ick; I concur with your judgment on those aspects of the IPC::Cmd design.
> Thanks for investigating.  So, surviving options include:

> 1. Require IPC::Run.
> 2. Write our own run() that reports the raw exit code.
> 3. Distill the raw exit code from the IPC::Cmd::run() error string.
> 4. Pass IPC::Run::run_forked() a subroutine that execs an argument list.

> Any others worth noting?

From a user-inconvenience standpoint, I think requiring IPC::Run is not
horrid, so long as we add an --enable-something configure option to drive
whether the TAP tests are run or skipped.  However, it has to work with
whatever version of IPC::Run the platform's Perl installation comes up
with, and in that regard I'm a bit worried.  I'm sitting here watching a
trial run on prairiedog (OSX 10.4.11, perl 5.8.6), and there seems to be
something extremely wrong from a performance standpoint.  For example:

t/001_pg_controldata.pl .. 
1..13
ok 1 - pg_controldata --help exit code 0
ok 2 - pg_controldata --help goes to stdout
ok 3 - pg_controldata --help nothing to stderr
ok 4 - pg_controldata --version exit code 0
ok 5 - pg_controldata --version goes to stdout
ok 6 - pg_controldata --version nothing to stderr
ok 7 - pg_controldata with invalid option nonzero exit code
ok 8 - pg_controldata with invalid option prints error message
ok 9 - pg_controldata without arguments fails
ok 10 - pg_controldata with nonexistent directory fails
ok 11 - pg_controldata /Users/tgl/pgsql/src/bin/pg_controldata/tmp_testOtBj/data exit code 0
ok 12 - pg_controldata /Users/tgl/pgsql/src/bin/pg_controldata/tmp_testOtBj/data no stderr
ok 13 - pg_controldata produces output: matches
ok
All tests successful.
Files=1, Tests=13, 32 wallclock secs ( 0.23 usr  0.05 sys + 21.97 cusr  7.82 csys = 30.07 CPU)
Result: PASS

Yup, you read that right, it took 32 seconds to run those dozen utterly
trivial tests.  As far as I could tell by eyeball, pretty much all of the
time went into test 11, which is odd since it seems not significantly
different from the others.  I think there's something wacky about IPC::Run
on this platform.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: pg_basebackup vs. Windows and tablespaces
Next
From: Andres Freund
Date:
Subject: Re: TAP test breakage on MacOS X