Обсуждение: 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

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

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

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

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