Re: tests and meson - test names and file locations - Mailing list pgsql-hackers

From Andres Freund
Subject Re: tests and meson - test names and file locations
Date
Msg-id 20220811192713.7sb7r4prujzj4jso@awork3.anarazel.de
Whole thread Raw
In response to Re: tests and meson - test names and file locations  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

On 2022-08-11 13:06:35 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > = Log and Data locations =
> 
> > To make things like the selection of log files for a specific test easier,
> > I've so far set it up so that test data and logs are stored in a separate
> > directory from the sources.
> 
> > testrun/<main|recovery|...>/<testname>/<log|tmp_check|results...>
> 
> > I do wonder if we should put test data and log files in a separate directory
> > tree, but that'd be a bit more work probably.
> 
> I'm confused, didn't you just say you already did that?

I did separate the source / build tree from the test log files / data files,
but not the test log files from the test data files. It'd be easy enough to
achieve for pg_regress tests, but perhaps a bit harder for things like
027_stream_regress.pl that run pg_regress themselves.


> > Here's an example output that you mostly should be able to make sense of now:
> 
> TBH, this seems to be almost all the same sort of useless noise that
> we have worked to suppress in "make" output.

Which part have we suppressed that's shown here? We've been talking about
cutting down the pointless information that pg_regress produces, but that
seems like a separate endeavor.


> The only thing that's of any interest at all is the report that the "cube"
> test failed, and you have managed to make it so that that report is pretty
> voluminous and yet contains not one useful detail.

It'll just print the list of tests and their success / failure, without
printing the test's output, if you don't pass --print-errorlogs.

The reason the commmand is shown is so you can copy-paste it to run the tests
on its own, which can be useful for debugging, it'll include all the
environment variables set when the test was run, so it's actually the same
command (not like right now, were some env variables are set via export in the
makefile).  We probably can make the command shorter - but that's pretty
similar to what's done for the make invocation of the tests.


> I still have to go and look at other log files to figure out what happened;
> and if I need to see the postmaster log, it's not even apparent where that
> is.

There's a hint at the start, but it could stand to be reformulated to point
that out more clearly:

# executing test in /tmp/meson/testrun/cube/pg_regress group cube test pg_regress, builddir /tmp/meson/contrib/cube


> I also wonder where, say, a core dump might wind up.

That'll depend on system configuration as before. Most commonly in the data
dir. Are you wondering where the data dir is?


> I'm failing to see any advance at all here over what we have now.
> If anything, the signal-to-noise ratio has gotten worse.

I'm surprised - I find it *vastly* more readable, because it'll show this
stuff only for the failed tests, and it'll tell you the failed tests at the
end. I don't know how many hours I've spent going backward through check-world
output to find the first failed tests, but it's many.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints
Next
From: David Rowley
Date:
Subject: Re: avoid negating LONG_MIN in cash_out()