Re: [HACKERS] proposal: separate databases for contrib module testing
On 12/02/2012 11:29 AM, Tom Lane wrote: Andrew Dunstan 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 *** 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) -- 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] proposal: separate databases for contrib module testing
Andrew Dunstan 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
Re: [HACKERS] proposal: separate databases for contrib module testing
On 12/02/2012 10:05 AM, Tom Lane wrote: Andrew Dunstan 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
Re: [HACKERS] proposal: separate databases for contrib module testing
Andrew Dunstan 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
[HACKERS] 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
