Re: pg_upgrade automatic testing

On 11/27/2011 06:17 PM, Tom Lane wrote:
> Peter Eisentraut<peter_e(at)gmx(dot)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