Re: [HACKERS] make check changes have caused buildfarm deterioration.

2015-07-24 Thread Jeff Janes
On Tue, Jul 21, 2015 at 6:31 PM, Michael Paquier michael.paqu...@gmail.com
wrote:

 On Wed, Jul 22, 2015 at 10:04 AM, Peter Eisentraut pete...@gmx.net
 wrote:
  On 7/21/15 10:00 AM, Tom Lane wrote:
  I agree; this change may have seemed like a good idea at the time, but
  it was not.  Failures during make check's install step are rare enough
  that you don't really need all that output in your face to help with the
  rare situation where it fails.  And for the buildfarm's purposes, it is
  surely desirable to segregate that output from the actual check step.
 
  It wasn't really an idea; it was just not necessary anymore.  We can put
  it [directing the make install output into a file] back if that's what
  people prefer.

 OK... Attached are two patches (please merge them into a single
 commit, I am just separating them as they are separate issues):
 - 0001 adds a missing entry in test_ddl_deparse's .gitignore. I
 mentioned that upthread.
 - 0002 redirects the installation logs into
 abs_top_builddir/tmp_install/log/install.log. We could redirect it
 only to abs_top_builddir/log/ but tmp_install is not removed after a
 run of a regression make target.


If I run 'make check' on an unbuilt tree, any compiler warnings emitted
during the build phase now get directed into the install log.  Was that
intentional or a side effect?

Cheers,

Jeff


Re: [HACKERS] make check changes have caused buildfarm deterioration.

2015-07-24 Thread Andrew Dunstan


On 07/24/2015 01:21 PM, Jeff Janes wrote:
On Tue, Jul 21, 2015 at 6:31 PM, Michael Paquier 
michael.paqu...@gmail.com mailto:michael.paqu...@gmail.com wrote:


On Wed, Jul 22, 2015 at 10:04 AM, Peter Eisentraut
pete...@gmx.net mailto:pete...@gmx.net wrote:
 On 7/21/15 10:00 AM, Tom Lane wrote:
 I agree; this change may have seemed like a good idea at the
time, but
 it was not.  Failures during make check's install step are
rare enough
 that you don't really need all that output in your face to help
with the
 rare situation where it fails.  And for the buildfarm's
purposes, it is
 surely desirable to segregate that output from the actual check
step.

 It wasn't really an idea; it was just not necessary anymore.  We
can put
 it [directing the make install output into a file] back if
that's what
 people prefer.

OK... Attached are two patches (please merge them into a single
commit, I am just separating them as they are separate issues):
- 0001 adds a missing entry in test_ddl_deparse's .gitignore. I
mentioned that upthread.
- 0002 redirects the installation logs into
abs_top_builddir/tmp_install/log/install.log. We could redirect it
only to abs_top_builddir/log/ but tmp_install is not removed after a
run of a regression make target.


If I run 'make check' on an unbuilt tree, any compiler warnings 
emitted during the build phase now get directed into the install log.  
Was that intentional or a side effect?






Probably not, but you could get around it easily by doing make  make 
check. Getting around the previous behavior was not nearly so easy.


cheers

andrew



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] make check changes have caused buildfarm deterioration.

2015-07-21 Thread Peter Eisentraut
On 7/21/15 10:00 AM, Tom Lane wrote:
 I agree; this change may have seemed like a good idea at the time, but
 it was not.  Failures during make check's install step are rare enough
 that you don't really need all that output in your face to help with the
 rare situation where it fails.  And for the buildfarm's purposes, it is
 surely desirable to segregate that output from the actual check step.

It wasn't really an idea; it was just not necessary anymore.  We can put
it [directing the make install output into a file] back if that's what
people prefer.

 A possible alternative is to run the make install sub-step with -s,
 but that could be objected to on the grounds that if it did fail, you'd
 have a hard time telling exactly which step failed.

I usually run the whole make check with -s.



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] make check changes have caused buildfarm deterioration.

2015-07-21 Thread Michael Paquier
On Tue, Jul 21, 2015 at 10:34 PM, Andrew Dunstan wrote:
 OK, looks sane enough. but please do address the other issue.

Okidoki.
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] make check changes have caused buildfarm deterioration.

2015-07-21 Thread Michael Paquier
On Wed, Jul 22, 2015 at 10:04 AM, Peter Eisentraut pete...@gmx.net wrote:
 On 7/21/15 10:00 AM, Tom Lane wrote:
 I agree; this change may have seemed like a good idea at the time, but
 it was not.  Failures during make check's install step are rare enough
 that you don't really need all that output in your face to help with the
 rare situation where it fails.  And for the buildfarm's purposes, it is
 surely desirable to segregate that output from the actual check step.

 It wasn't really an idea; it was just not necessary anymore.  We can put
 it [directing the make install output into a file] back if that's what
 people prefer.

OK... Attached are two patches (please merge them into a single
commit, I am just separating them as they are separate issues):
- 0001 adds a missing entry in test_ddl_deparse's .gitignore. I
mentioned that upthread.
- 0002 redirects the installation logs into
abs_top_builddir/tmp_install/log/install.log. We could redirect it
only to abs_top_builddir/log/ but tmp_install is not removed after a
run of a regression make target.
-- 
Michael
From 0614062b1d41bd72ed4a0ba000d639607156066d Mon Sep 17 00:00:00 2001
From: Michael Paquier michael@otacoo.com
Date: Wed, 22 Jul 2015 10:15:20 +0900
Subject: [PATCH 1/2] Add missing entry log/ in .gitignore for test_ddl_deparse

Entry forgotten by 9faa6ae1.
---
 src/test/modules/test_ddl_deparse/.gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/test/modules/test_ddl_deparse/.gitignore b/src/test/modules/test_ddl_deparse/.gitignore
index 6628455..3337b3d 100644
--- a/src/test/modules/test_ddl_deparse/.gitignore
+++ b/src/test/modules/test_ddl_deparse/.gitignore
@@ -1 +1,2 @@
+/log/
 /results/
-- 
2.4.6

From 9df069d70f8c9aecf7254ebfdec85460faf5 Mon Sep 17 00:00:00 2001
From: Michael Paquier michael@otacoo.com
Date: Wed, 22 Jul 2015 10:24:17 +0900
Subject: [PATCH 2/2] Redirect installation output of make check into a log
 file

dbf2ec1a changed make check such as the installation logs get directed
to stdout and stderr, however some recent objections are proving that this
was a bad move. Hence put it back into a log file saved as tmp_install/log
which is created once per invocation of any make target doing regression
tests.
---
 src/Makefile.global.in | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/Makefile.global.in b/src/Makefile.global.in
index 8d1250d..e2f7211 100644
--- a/src/Makefile.global.in
+++ b/src/Makefile.global.in
@@ -307,9 +307,10 @@ temp-install:
 ifndef NO_TEMP_INSTALL
 ifeq ($(MAKELEVEL),0)
 	rm -rf '$(abs_top_builddir)'/tmp_install
-	$(MAKE) -C '$(top_builddir)' DESTDIR='$(abs_top_builddir)'/tmp_install install
+	$(MKDIR_P) '$(abs_top_builddir)'/tmp_install/log
+	$(MAKE) -C '$(top_builddir)' DESTDIR='$(abs_top_builddir)'/tmp_install install '$(abs_top_builddir)'/tmp_install/log/install.log 21
 endif
-	$(if $(EXTRA_INSTALL),for extra in $(EXTRA_INSTALL); do $(MAKE) -C '$(top_builddir)'/$$extra DESTDIR='$(abs_top_builddir)'/tmp_install install || exit; done)
+	$(if $(EXTRA_INSTALL),for extra in $(EXTRA_INSTALL); do $(MAKE) -C '$(top_builddir)'/$$extra DESTDIR='$(abs_top_builddir)'/tmp_install install '$(abs_top_builddir)'/tmp_install/log/install.log || exit; done)
 endif
 
 PROVE = @PROVE@
-- 
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


Re: [HACKERS] make check changes have caused buildfarm deterioration.

2015-07-21 Thread Andres Freund
On 2015-07-21 14:39:42 +0900, Michael Paquier wrote:
 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.

FWIW, I think that's bad TM. Especially when comparing good/bad
buildfarm runs the ability to get logs from good runs is essential.

Andres


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] make check changes have caused buildfarm deterioration.

2015-07-21 Thread Alvaro Herrera
Michael Paquier wrote:
 On Tue, Jul 21, 2015 at 2:39 PM, Michael Paquier
 michael.paqu...@gmail.com wrote:

  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.
 
 Something I just noticed: an entry for log/ in test_ddl_deparse's
 gitignore is missing.

Well, three things: 1) the entry is not missing right now, but it will
be missing if we apply your patch; 2) the file is inconsistent with the
other test modules anyway so we might as well apply your patch to make
them all alike; 3) we shouldn't really do anything about that until the
other patch's fate is decided.

So, regarding the other patch, I don't know if it's that useful to keep
the log files when the check succeeds; and if it fails, the only problem
we have, I think, is that the path is wrong in the buildfarm code and
that seems easily fixed, but do we want to make the master branch
different from the others?  Maybe the BF code can look up the new path
first, and if it can't find the file then look in the old path.

Unless I'm misunderstanding the whole thing.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training  Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] make check changes have caused buildfarm deterioration.

2015-07-21 Thread Alvaro Herrera
Andres Freund wrote:
 On 2015-07-21 14:39:42 +0900, Michael Paquier wrote:
  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.
 
 FWIW, I think that's bad TM. Especially when comparing good/bad
 buildfarm runs the ability to get logs from good runs is essential.

Hm, okay, so let's put it back where it was.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training  Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] make check changes have caused buildfarm deterioration.

2015-07-21 Thread Michael Paquier
On Tue, Jul 21, 2015 at 7:01 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
 Michael Paquier wrote:
 On Tue, Jul 21, 2015 at 2:39 PM, Michael Paquier
 michael.paqu...@gmail.com wrote:

  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.

 Something I just noticed: an entry for log/ in test_ddl_deparse's
 gitignore is missing.

 Well, three things: 1) the entry is not missing right now, but it will
 be missing if we apply your patch; 2) the file is inconsistent with the
 other test modules anyway so we might as well apply your patch to make
 them all alike; 3) we shouldn't really do anything about that until the
 other patch's fate is decided.

Well, just to be clear, I meant with the previous patch I have attached.
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] make check changes have caused buildfarm deterioration.

2015-07-21 Thread Tom Lane
Andrew Dunstan andrew.duns...@pgexperts.com writes:
 On 07/21/2015 01:39 AM, Michael Paquier wrote:
 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.

 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.

I agree; this change may have seemed like a good idea at the time, but
it was not.  Failures during make check's install step are rare enough
that you don't really need all that output in your face to help with the
rare situation where it fails.  And for the buildfarm's purposes, it is
surely desirable to segregate that output from the actual check step.

A possible alternative is to run the make install sub-step with -s,
but that could be objected to on the grounds that if it did fail, you'd
have a hard time telling exactly which step failed.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] make check changes have caused buildfarm deterioration.

2015-07-21 Thread Andrew Dunstan

On 07/21/2015 01:39 AM, Michael Paquier wrote:

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=crakedt=2015-07-20%2013%3A09%3A02stg=check
and
http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=crakedt=2015-07-20%2017%3A23%3A08stg=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.



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


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] make check changes have caused buildfarm deterioration.

2015-07-20 Thread Tom Lane
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=crakedt=2015-07-20%2013%3A09%3A02stg=check
  
 and 
 http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=crakedt=2015-07-20%2017%3A23%3A08stg=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.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] make check changes have caused buildfarm deterioration.

2015-07-20 Thread Michael Paquier
On Tue, Jul 21, 2015 at 2:39 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
 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=crakedt=2015-07-20%2013%3A09%3A02stg=check
 and
 http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=crakedt=2015-07-20%2017%3A23%3A08stg=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.

Something I just noticed: an entry for log/ in test_ddl_deparse's
gitignore is missing.
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] make check changes have caused buildfarm deterioration.

2015-07-20 Thread Michael Paquier
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=crakedt=2015-07-20%2013%3A09%3A02stg=check
 and
 http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=crakedt=2015-07-20%2017%3A23%3A08stg=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