proposal: separate databases for contrib module testing
I'd like to change the way we set the CONTRIB_TESTDB name for contrib
modules. so that each module doesn't wipe out the previous module's test
db. The reason is that this will let us test upgrading them using
pg_upgrade much more easily. Not testing this is a significant hole in
the pg_upgrade testing regime.
This can be achieved by a fairly simple change in Makefile.global.in
along these lines:
ifneq ($(MODULE_big),)
CONTRIB_TESTDB = contrib_regression_$(MODULE_big)
else
ifneq ($(MODULES),)
CONTRIB_TESTDB = contrib_regression_$(MODULES)
else
CONTRIB_TESTDB = contrib_regression
endif
endif
plus some changes in the dblink tests / results that rely on the
database name.
The downside is that this involves in increase in space of 6.5Mb to
7.5Mb per module. That doesn't seem huge in these days when a standard
commodity hard drive is 500Gb and up.
Thoughts?
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
Andrew Dunstan <andrew@dunslane.net> writes:
I'd like to change the way we set the CONTRIB_TESTDB name for contrib
modules. so that each module doesn't wipe out the previous module's test
db.
Personally I always thought that was a feature not a bug. If we give
each one its own DB, there will be a couple of dozen databases
cluttering the installation at the end of "make installcheck", and no
convenient way to get rid of them. Moreover, what I think you've got
in mind doesn't work in the "make check" case anyway --- you'd have
little alternative but to test upgrading each one separately.
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
On 12/02/2012 10:05 AM, Tom Lane wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
I'd like to change the way we set the CONTRIB_TESTDB name for contrib
modules. so that each module doesn't wipe out the previous module's test
db.Personally I always thought that was a feature not a bug. If we give
each one its own DB, there will be a couple of dozen databases
cluttering the installation at the end of "make installcheck", and no
convenient way to get rid of them. Moreover, what I think you've got
in mind doesn't work in the "make check" case anyway --- you'd have
little alternative but to test upgrading each one separately.
The last point at least doesn't seem relevant. The test script we
currently use for pg_upgrade uses "make installcheck" and the new
cross-version upgrade testing I'm working on relies on having the items
to be upgraded established via "make installcheck".
How about if we have a make target to clean these databases out,
"installcheck-clean", maybe? Alternatively, or in addition, how about if
we have a separate make target to do things the way I'm suggesting,
assuming I can make that work?
Testing upgrading each contrib module separately is really very sub-optimal.
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
Andrew Dunstan <andrew@dunslane.net> writes:
On 12/02/2012 10:05 AM, Tom Lane wrote:
Personally I always thought that was a feature not a bug. If we give
each one its own DB, there will be a couple of dozen databases
cluttering the installation at the end of "make installcheck", and no
convenient way to get rid of them.
How about if we have a make target to clean these databases out,
"installcheck-clean", maybe? Alternatively, or in addition, how about if
we have a separate make target to do things the way I'm suggesting,
assuming I can make that work?
Either of those would satisfy my concern. The latter might be a bit
easier, not sure.
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
On 12/02/2012 11:29 AM, Tom Lane wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
On 12/02/2012 10:05 AM, Tom Lane wrote:
Personally I always thought that was a feature not a bug. If we give
each one its own DB, there will be a couple of dozen databases
cluttering the installation at the end of "make installcheck", and no
convenient way to get rid of them.How about if we have a make target to clean these databases out,
"installcheck-clean", maybe? Alternatively, or in addition, how about if
we have a separate make target to do things the way I'm suggesting,
assuming I can make that work?Either of those would satisfy my concern. The latter might be a bit
easier, not sure.
Yeah. This lets me get what I want, via "make USE_MODULE_DB=1
installcheck", don't even need a new target. There's probably a case for
doing the same sort of thing for the pl_* makefiles on the basis of
consistency, not sure if it's worth it though.
cheers
andrew
Attachments:
module_db.patchtext/x-patch; name=module_db.patchDownload
*** a/contrib/dblink/Makefile
--- b/contrib/dblink/Makefile
***************
*** 11,16 **** DATA = dblink--1.1.sql dblink--1.0--1.1.sql dblink--unpackaged--1.0.sql
--- 11,19 ----
REGRESS = dblink
+ # the db name is hard-coded in the tests
+ override undefine USE_MODULE_DB
+
ifdef USE_PGXS
PG_CONFIG = pg_config
PGXS := $(shell $(PG_CONFIG) --pgxs)
*** a/src/Makefile.global.in
--- b/src/Makefile.global.in
***************
*** 428,433 **** submake-libpgport:
--- 428,442 ----
PL_TESTDB = pl_regression
CONTRIB_TESTDB = contrib_regression
+ ifneq ($(MODULE_big),)
+ CONTRIB_TESTDB_MODULE = contrib_regression_$(MODULE_big)
+ else
+ ifneq ($(MODULES),)
+ CONTRIB_TESTDB_MODULE = contrib_regression_$(MODULES)
+ else
+ CONTRIB_TESTDB_MODULE = contrib_regression
+ endif
+ endif
ifdef NO_LOCALE
NOLOCALE += --no-locale
*** a/src/makefiles/pgxs.mk
--- b/src/makefiles/pgxs.mk
***************
*** 240,246 **** distclean maintainer-clean: clean
ifdef REGRESS
# Select database to use for running the tests
! REGRESS_OPTS += --dbname=$(CONTRIB_TESTDB)
# where to find psql for running the tests
PSQLDIR = $(bindir)
--- 240,250 ----
ifdef REGRESS
# Select database to use for running the tests
! ifdef USE_MODULE_DB
! REGRESS_OPTS += --dbname=$(CONTRIB_TESTDB_MODULE)
! else
! REGRESS_OPTS += --dbname=$(CONTRIB_TESTDB)
! endif
# where to find psql for running the tests
PSQLDIR = $(bindir)