Re: "make check" changes have caused buildfarm deterioration.

On 07/21/2015 01:39 AM, Michael Paquier wrote:
> On Tue, Jul 21, 2015 at 6:17 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Andrew Dunstan <andrew(dot)dunstan(at)pgexperts(dot)com> writes:
>>> Somewhere along the way some changes to the way we do "make check" have
>>> caused a significant deterioration in the buildfarm's logging. Compare
>>> these two from animal crake, which happens to be my test instance:
>>> <http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=crake&dt=2015-07-20%2013%3A09%3A02&stg=check>
>>> and
>>> <http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=crake&dt=2015-07-20%2017%3A23%3A08&stg=check>
>> Yeah, I've been bitching about the poor logging for awhile, but I had
>> not realized that it's still working as-expected in the back branches.
>>
>> Comparing different branches, it looks like "somewhere along the way"
>> means "between 9.4 and 9.5". I suspect that commit dcae5faccab64776, or
>> perhaps the followon dbf2ec1a1c053379, is to blame.
> Regarding install.log, the use of stdout/stderr instead of a log file
> has been changed in dbf2ec1a after that:
> http://www.postgresql.org/message-id/553FE7FC.2040707@gmx.net
> Since 9.5 as the location of the temporary installation is global, we
> could basically revert some parts of dcae5fac if that helps so as
> install.log is saved in $ROOT/tmp_install/log/install.log... But I am
> not sure what we win with that, and the argument to remove install.log
> is that now the temporary installation is a make target. Both ways
> have advantages and disadvantages.

I'm quite unhappy about how we now pollute the output of "make check"
with the install log. See the above links for why. And when I run it by
hand I don't want all this scrolling by me on the screen. The previous
output of "make check" was small and clean, and I want it to go back to
that, with the other logs available as necessary. The reason the
buildfarm client cd's into the regress directory to run "make check" is
to avoid extraneous output.

>
> Regarding initdb.log and postmaster.log, this is definitely a bug.
> Those have been moved by dcae5fa from log/ to tmp_check/log/,
> tmp_check/ getting removed at the end of pg_regress if there are no
> failures counted. Both files will be saved in log/ at the location
> pg_regress is called using outputdir whose default is ".". This way
> behavior is similar to ~9.4. Attached is a patch to fix this for 9.5
> and master.

OK, looks sane enough. but please do address the other issue.

cheers

andrew