Re: making pg_regress less noisy by removing boilerplate - Mailing list pgsql-hackers

From Andres Freund
Subject Re: making pg_regress less noisy by removing boilerplate
Date
Msg-id 20220221183240.sig76qdfyrdwjsfi@alap3.anarazel.de
Whole thread Raw
In response to Re: making pg_regress less noisy by removing boilerplate  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

On 2022-02-21 12:40:18 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2022-02-21 12:05:42 -0500, Tom Lane wrote:
> >> except maybe the "running on port 51696 with PID 1156405" line (and I'm not
> >> too wedded to that)?
> 
> > We still have a few issues with ports conflicts on windows. We should really
> > consider just desupporting all windows versions without unix socket
> > support. But until then it seems useful to be able to figure out random
> > failures.
> 
> Yeah, also it seems useful to distinguish installcheck and check cases.
> With context removed, it might not make as much sense as it does today,
> so I'd vote for adding a word or two.  Perhaps the output could
> look like
> 
>     test postmaster started on port 51696 with PID 1156405
>     "testname ... ok" lines here
>     test postmaster stopped
>     "all tests passed" or "n tests passed" here

I'm all for something minimal like this.

I guess we could just try to go for a tap compatible output, but it'd probably
be too annoying to not see the test name when it starts.

Perhaps we could still take a page out of tap's book, and denote non-test
output lines by starting with an #, so it's visually obvious what are lines
about tests?


It'd probably not be a good idea to backpatch this, even if it'd be nice to
have at least semi-consistent formatting across branches? Too likely somebody
built scripts depending on the old format?


> >> It'd also be a good idea to start using "make -s" by default for the
> >> preparatory steps.
> 
> > For the temp-install and checkprep targets, or for something else? That'd
> > probably just be a few @'s in front of rm, mkdir?
> 
> Well, all that stuff is interesting only in case of a failure.


> > One thing with temp-install that's been bothering me is that it often hides
> > compilation failures inside install.log,
> 
> Yeah, I've run into that too --- even if there's no failure, you'll
> never see any compiler warnings.  Perhaps if we started using
> "make -s" we'd not need install.log at all, and could just let
> errors/warnings spew to stderr where the user would see 'em.

WFM.  I'd still like to address the issue of building contrib with -j1 (due to
checkprep ending up building contrib). But we can do that separately too.

I assume we'd want to do this in all branches?

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Time to drop plpython2?
Next
From: "Imseih (AWS), Sami"
Date:
Subject: Re: Add index scan progress to pg_stat_progress_vacuum