Re: pg_upgrade automatic testing

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_upgrade automatic testing
Дата
Msg-id 20327.1322435869@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_upgrade automatic testing  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: pg_upgrade automatic testing  (Andrew Dunstan <andrew@dunslane.net>)
Re: pg_upgrade automatic testing  (Andrew Dunstan <andrew@dunslane.net>)
Re: pg_upgrade automatic testing  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
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?
        regards, tom lane


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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: pg_upgrade automatic testing
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: logging in high performance systems.