Re: TAP test breakage on MacOS X

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: TAP test breakage on MacOS X
Date: 2014-10-30 15:13:06
Message-ID: 20973.1414681986@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Noah Misch <noah(at)leadboat(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-10-30 15:54:25 Re: TAP test breakage on MacOS X
Previous Message Amit Kapila 2014-10-30 14:18:42 Re: pg_basebackup vs. Windows and tablespaces