| From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
|---|---|
| To: | Noah Misch <noah(at)leadboat(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-11-03 21:36:14 |
| Message-ID: | 5457F54E.4020805@gmx.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 11/2/14 2:00 PM, Noah Misch wrote:
>> 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.
>
> FWIW, (3) looks most promising to me. That is to say, implement a reverse of
> IPC::Cmd::_pp_child_error(). Ugly to be sure, but the wart can be small and
> self-contained.
I thank you for this research, but I suggest that we ship 9.4 as is,
that is with requiring IPC::Run and --enable-* option. All the possible
alternatives will clearly need more rounds of portability testing. We
can then evaluate these changes for 9.5 in peace.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2014-11-03 21:40:39 | Re: TAP test breakage on MacOS X |
| Previous Message | Peter Eisentraut | 2014-11-03 21:26:11 | Re: tracking commit timestamps |