Re: proposal: separate databases for contrib module testing

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: proposal: separate databases for contrib module testing
Дата
Msg-id 50BB76E7.4090803@dunslane.net
обсуждение исходный текст
Ответ на Re: proposal: separate databases for contrib module testing  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: proposal: separate databases for contrib module testing
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jan Wieck
Дата:
Сообщение: Re: autovacuum truncate exclusive lock round two
Следующее
От: Tom Lane
Дата:
Сообщение: Re: proposal: separate databases for contrib module testing