On 11/27/2011 06:17 PM, Tom Lane wrote:
Peter Eisentraut<pete...@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.sql
differ
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
