separate output dirs for test decoding pieces.

Started by Andrew Dunstanalmost 12 years ago3 messages
#1Andrew Dunstan
andrew@dunslane.net
1 attachment(s)

"make check" in contrib/test_decoding actually does two regression runs,
one with pg_regress and one with pg_isolation_regress. These both use
the same (default) outputdir, so one overwrites the other, which is a
bit unfortunate from the buildfarm's point of view. I propose to make
them use separate outputdirs, via the attached small patch.

Comments?

cheers

andrew

Attachments:

testdecoding.patchtext/x-patch; name=testdecoding.patchDownload
diff --git a/contrib/test_decoding/Makefile b/contrib/test_decoding/Makefile
index c193f73..d6e6a6b 100644
--- a/contrib/test_decoding/Makefile
+++ b/contrib/test_decoding/Makefile
@@ -5,7 +5,7 @@ OBJS = test_decoding.o
 
 # Note: because we don't tell the Makefile there are any regression tests,
 # we have to clean those result files explicitly
-EXTRA_CLEAN = -r $(pg_regress_clean_files)
+EXTRA_CLEAN = $(pg_regress_clean_files) ./regression_output ./isolation_output
 
 ifdef USE_PGXS
 PG_CONFIG = pg_config
@@ -40,10 +40,12 @@ submake-test_decoding:
 REGRESSCHECKS=ddl rewrite toast permissions decoding_in_xact binary
 
 regresscheck: all | submake-regress submake-test_decoding
+	$(MKDIR_P) regression_output
 	$(pg_regress_check) \
 	    --temp-config $(top_srcdir)/contrib/test_decoding/logical.conf \
 	    --temp-install=./tmp_check \
 	    --extra-install=contrib/test_decoding \
+	    --outputdir=./regress_output \
 	    $(REGRESSCHECKS)
 
 regresscheck-install-force: | submake-regress submake-test_decoding
@@ -54,9 +56,11 @@ regresscheck-install-force: | submake-regress submake-test_decoding
 ISOLATIONCHECKS=mxact delayed_startup concurrent_ddl_dml
 
 isolationcheck: all | submake-isolation submake-test_decoding
+	$(MKDIR_P) isolation_output
 	$(pg_isolation_regress_check) \
 	    --temp-config $(top_srcdir)/contrib/test_decoding/logical.conf \
 	    --extra-install=contrib/test_decoding \
+	    --outputdir=./isolation_output \
 	    $(ISOLATIONCHECKS)
 
 isolationcheck-install-force: all | submake-isolation submake-test_decoding
#2Andres Freund
andres@2ndquadrant.com
In reply to: Andrew Dunstan (#1)
Re: separate output dirs for test decoding pieces.

Hi,

On 2014-03-29 13:20:41 -0400, Andrew Dunstan wrote:

"make check" in contrib/test_decoding actually does two regression runs, one
with pg_regress and one with pg_isolation_regress. These both use the same
(default) outputdir, so one overwrites the other, which is a bit unfortunate
from the buildfarm's point of view. I propose to make them use separate
outputdirs, via the attached small patch.

Comments?

Thanks for taking care of this, sounds like a good idea.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, 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

#3Robert Haas
robertmhaas@gmail.com
In reply to: Andres Freund (#2)
Re: separate output dirs for test decoding pieces.

On Mon, Mar 31, 2014 at 5:27 AM, Andres Freund <andres@2ndquadrant.com> wrote:

On 2014-03-29 13:20:41 -0400, Andrew Dunstan wrote:

"make check" in contrib/test_decoding actually does two regression runs, one
with pg_regress and one with pg_isolation_regress. These both use the same
(default) outputdir, so one overwrites the other, which is a bit unfortunate
from the buildfarm's point of view. I propose to make them use separate
outputdirs, via the attached small patch.

Comments?

Thanks for taking care of this, sounds like a good idea.

It's a little weird that the normal directory name is "results" and
now we have "regression_output" and "isolation_output". Why
s/results/output/?

Also, the patch failed to update .gitignore, which I have now done.
If we do any further renaming here, .gitignore should not miss the
bus.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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