Re: TAP test breakage on MacOS X

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(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-07 04:15:08
Message-ID: 10559.1412655308@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Oct 6, 2014 at 8:15 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>> 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.

The given case seemed pretty opaque to me too. Could we maybe
have some documentation about how to debug TAP failures? Or in
other words, if they're "arguably" easier to debug, how about
presenting that argument?

Also to the point: does the buildfarm script know how to collect
the information needed to debug a TAP failure?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-10-07 04:24:05 Re: replicating DROP commands across servers
Previous Message Robert Haas 2014-10-07 04:07:09 Re: TAP test breakage on MacOS X