Re: making pg_regress less noisy by removing boilerplate

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: making pg_regress less noisy by removing boilerplate
Дата
Msg-id 522318.1645465218@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: making pg_regress less noisy by removing boilerplate  (Andres Freund <andres@anarazel.de>)
Ответы Re: making pg_regress less noisy by removing boilerplate  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: RFC: Logging plan of the running query
Следующее
От: Mark Wong
Дата:
Сообщение: Re: Time to drop plpython2?