Thread

1. proposal: separate databases for contrib module testing

   Andrew Dunstan <andrew@dunslane.net> — 2012-12-02T04:33:25Z

   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
   
   
   

2. Re: proposal: separate databases for contrib module testing

   Tom Lane <tgl@sss.pgh.pa.us> — 2012-12-02T15:05:53Z

   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
   
   
   

3. Re: proposal: separate databases for contrib module testing

   Andrew Dunstan <andrew@dunslane.net> — 2012-12-02T15:42:31Z

   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
   
   
   

4. Re: proposal: separate databases for contrib module testing

   Tom Lane <tgl@sss.pgh.pa.us> — 2012-12-02T16:29:44Z

   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
   
   
   

5. Re: proposal: separate databases for contrib module testing

   Andrew Dunstan <andrew@dunslane.net> — 2012-12-02T17:36:32Z

   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