Re: pg_upgrade automatic testing

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: pg_upgrade automatic testing
Дата
Msg-id 4ED40060.10208@dunslane.net
обсуждение исходный текст
Ответ на Re: pg_upgrade automatic testing  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers

On 11/27/2011 06:17 PM, Tom Lane wrote:
> Peter Eisentraut<peter_e@gmx.net>  writes:
>> I've committed it now, and some buildfarm members are failing with lack
>> of shared memory, semaphores, or disk space.  Don't know what to do with
>> that or why so many are failing like that.  We could create a way to
>> omit the test if it becomes a problem.
> I believe the issue is that those BF members have kernel settings that
> only support running one postmaster at a time.  The way you've got this
> set up, it launches a new private postmaster during a make installcheck;
> which is not only problematic from a resource consumption standpoint,
> but seems to me to violate the spirit of make installcheck, because
> what it's testing is not the installed postmaster but a local instance.
>
> Can you confine the test to only occur in "make check" mode, not "make
> installcheck", please?



Another thing that's annoying about this is that it doesn't give you any 
idea of how it's failing if there's a database difference. All we get is:
   Files /home/pgrunner/bf/root/HEAD/pgsql.3188/contrib/pg_upgrade/tmp_check/dump1.sql and
/home/pgrunner/bf/root/HEAD/pgsql.3188/contrib/pg_upgrade/tmp_check/dump2.sqldiffer
 


See 
<http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=frogmouth&dt=2011-11-28%2019%3A30%3A03> 
for an example. For buildfarm purposes this is pretty low grade info, ISTM.

cheers

andrew




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

Предыдущее
От: Dimitri Fontaine
Дата:
Сообщение: Re: Patch: add timing of buffer I/O requests
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: strange nbtree corruption report