Re: making pg_regress less noisy by removing boilerplate

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org, Daniel Gustafsson <daniel(at)yesql(dot)se>
Subject: Re: making pg_regress less noisy by removing boilerplate
Date: 2022-02-21 18:32:40
Message-ID: 20220221183240.sig76qdfyrdwjsfi@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2022-02-21 12:40:18 -0500, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Imseih (AWS), Sami 2022-02-21 19:03:39 Re: Add index scan progress to pg_stat_progress_vacuum
Previous Message Andres Freund 2022-02-21 18:05:37 Re: Time to drop plpython2?