Re: TAP test breakage on MacOS X
От | Tom Lane |
---|---|
Тема | Re: TAP test breakage on MacOS X |
Дата | |
Msg-id | 20973.1414681986@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: TAP test breakage on MacOS X (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: TAP test breakage on MacOS X
Re: TAP test breakage on MacOS X |
Список | 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 по дате отправления: