Re: pg_upgrade automatic testing - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_upgrade automatic testing
Date
Msg-id 20327.1322435869@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_upgrade automatic testing  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: pg_upgrade automatic testing
Re: pg_upgrade automatic testing
Re: pg_upgrade automatic testing
List 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 by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: pg_upgrade automatic testing
Next
From: Stephen Frost
Date:
Subject: Re: logging in high performance systems.