Re: TAP test breakage on MacOS X

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: TAP test breakage on MacOS X
Date: 2014-10-07 04:07:09
Message-ID: CA+TgmoZ+=BkF1bDC33sFXWV8J-P3DLy_7eTNtrOYEvRS5qtTfw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Oct 6, 2014 at 8:15 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On Thu, 2014-10-02 at 21:18 -0400, Robert Haas wrote:
>> > If none of this gets us closer to an answer, I can try to produce a
>> > patch that produces more details for such failures.
>>
>> A test that fails for no reason that can be gleaned from the output is
>> not an improvement over not having a test at all.
>
> I understand that this isn't great, and it's certainly something I'm
> looking into. But it's like pg_regress saying that psql crashed and
> leaving you to find out why. I don't think saying that the entire
> regression test suite is useless because of that is fair. The TAP tests
> are arguably already much easier to debug than pg_regress ever was.

Well, maybe. I wasn't able, after about 5 minutes of searching, to
locate either a log file with details of the failure or the code that
revealed what the test, the expected result, and the actual result
were. It's possible that all that information is there and I just
don't know where to look; it took me a while to learn where the
various logs (postmaster.log, initdb.log, results) left behind by
pg_regress were, too. If that information is not there, then I'd say
it's not easier to debug. If it is and I don't know where to look ...
well then I just need to get educated.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-10-07 04:15:08 Re: TAP test breakage on MacOS X
Previous Message Amit Kapila 2014-10-07 03:58:49 Re: pg_receivexlog always handles -d option argument as connstr