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

From Tom Lane
Subject Re: making pg_regress less noisy by removing boilerplate
Date
Msg-id 522318.1645465218@sss.pgh.pa.us
Whole thread Raw
In response to Re: making pg_regress less noisy by removing boilerplate  (Andres Freund <andres@anarazel.de>)
Responses Re: making pg_regress less noisy by removing boilerplate
List pgsql-hackers
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

>> 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.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: RFC: Logging plan of the running query
Next
From: Mark Wong
Date:
Subject: Re: Time to drop plpython2?