From: | Christoph Berg <cb(at)df7cb(dot)de> |
---|---|
To: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: TAP test breakage on MacOS X |
Date: | 2014-12-22 20:26:39 |
Message-ID: | 20141222202631.GB19094@msg.df7cb.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Re: Peter Eisentraut 2014-11-03 <5457F54E(dot)4020805(at)gmx(dot)net>
> 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.
Hrm. I spent some effort into getting the TAP tests to run on 9.4beta
for Debian, and I've only now learned that 9.4.0 doesn't run them
unless I say --enable-tap-tests. A short note to -packagers would have
been nice, for a change so late in the release cycle...
Christoph
--
cb(at)df7cb(dot)de | http://www.df7cb.de/
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2014-12-22 20:45:44 | Re: Role Attribute Bitmask Catalog Representation |
Previous Message | Petr Jelinek | 2014-12-22 20:21:58 | Re: TABLESAMPLE patch |