On Tue, Jul 21, 2015 at 6:17 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Andrew Dunstan <andrew.duns...@pgexperts.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.2040...@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.
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.
Regards,
--
Michael
From d113a885a2353da30a37424a3fed94b72922cdd0 Mon Sep 17 00:00:00 2001
From: Michael Paquier <michael@otacoo.com>
Date: Tue, 21 Jul 2015 14:27:59 +0900
Subject: [PATCH] Fix location of output logs of pg_regress
initdb.log and postmaster.log have been moved in the temporary instance
path by default tmp_check/log by dcae5fac, which gets removed at the end
of the run of pg_regress when there are no failures found. This makes
difficult analysis of after-run failures in some cases, and reduces the
output verbosity of buildfarm after a run.
Per report from Andrew Dunstan.
---
src/test/regress/pg_regress.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/test/regress/pg_regress.c b/src/test/regress/pg_regress.c
index ed8c369..dd65ab5 100644
--- a/src/test/regress/pg_regress.c
+++ b/src/test/regress/pg_regress.c
@@ -2207,7 +2207,7 @@ regression_main(int argc, char *argv[], init_function ifunc, test_function tfunc
make_directory(temp_instance);
/* and a directory for log files */
- snprintf(buf, sizeof(buf), "%s/log", temp_instance);
+ snprintf(buf, sizeof(buf), "%s/log", outputdir);
if (!directory_exists(buf))
make_directory(buf);
@@ -2220,10 +2220,10 @@ regression_main(int argc, char *argv[], init_function ifunc, test_function tfunc
temp_instance,
debug ? " --debug" : "",
nolocale ? " --no-locale" : "",
- temp_instance);
+ outputdir);
if (system(buf))
{
- fprintf(stderr, _("\n%s: initdb failed\nExamine %s/log/initdb.log for the reason.\nCommand was: %s\n"), progname, temp_instance, buf);
+ fprintf(stderr, _("\n%s: initdb failed\nExamine %s/log/initdb.log for the reason.\nCommand was: %s\n"), progname, outputdir, buf);
exit(2);
}
@@ -2324,7 +2324,7 @@ regression_main(int argc, char *argv[], init_function ifunc, test_function tfunc
bindir ? "/" : "",
temp_instance, debug ? " -d 5" : "",
hostname ? hostname : "", sockdir ? sockdir : "",
- temp_instance);
+ outputdir);
postmaster_pid = spawn_process(buf);
if (postmaster_pid == INVALID_PID)
{
@@ -2353,7 +2353,7 @@ regression_main(int argc, char *argv[], init_function ifunc, test_function tfunc
if (WaitForSingleObject(postmaster_pid, 0) == WAIT_OBJECT_0)
#endif
{
- fprintf(stderr, _("\n%s: postmaster failed\nExamine %s/log/postmaster.log for the reason\n"), progname, temp_instance);
+ fprintf(stderr, _("\n%s: postmaster failed\nExamine %s/log/postmaster.log for the reason\n"), progname, outputdir);
exit(2);
}
@@ -2361,7 +2361,7 @@ regression_main(int argc, char *argv[], init_function ifunc, test_function tfunc
}
if (i >= 60)
{
- fprintf(stderr, _("\n%s: postmaster did not respond within 60 seconds\nExamine %s/log/postmaster.log for the reason\n"), progname, temp_instance);
+ fprintf(stderr, _("\n%s: postmaster did not respond within 60 seconds\nExamine %s/log/postmaster.log for the reason\n"), progname, outputdir);
/*
* If we get here, the postmaster is probably wedged somewhere in
--
2.4.6
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
