Hi, On 2022-08-11 13:06:35 -0400, Tom Lane wrote: > Andres Freund <and...@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
