On 10/07/2014 09:53 AM, Andrew Dunstan wrote:
On 10/07/2014 12:15 AM, Tom Lane wrote:
Robert Haas <robertmh...@gmail.com> writes:
On Mon, Oct 6, 2014 at 8:15 PM, Peter Eisentraut <pete...@gmx.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?
No. In fact, it doesn't yet know how to run those tests. That's on my
TODO list.
OK, I have a preliminary cut at adding these tests to the client. See
<http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=crake&dt=2014-10-07%2015%3A38%3A04&stg=bin-check>
for an example run. The patch is at
<https://github.com/PGBuildFarm/client-code/commit/6f644b779c90b16f96e4454b807e804bde48b563>
I don't much like the idea of doing an install/initdb/start for every
directory in src/bin, though. Can't we at least manage a single
installation directory for all these?
Also I notice that the tests remove their data directories. That could
make collecting any diagnosis data more difficult. Right now, I have no
idea what I'm looking for anyway.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
