Re: buildfarm failures on smew and anole - Mailing list pgsql-hackers

From Robert Haas
Subject Re: buildfarm failures on smew and anole
Date
Msg-id CA+TgmoYjdrOmtphGDYrF4F45HhGvxa=j+LweUyXZ6v1q78WtEQ@mail.gmail.com
Whole thread Raw
In response to Re: buildfarm failures on smew and anole  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: buildfarm failures on smew and anole  (Andres Freund <andres@2ndquadrant.com>)
Re: buildfarm failures on smew and anole  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Oct 14, 2013 at 9:22 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
>> Maybe I didn't explain that well.  The problem is that the regression
>> tests require at least 20 connections to run, and those two machines
>> are currently auto-selecting 10 connections, so make check is failing.
>
> Why do they need 20 connections? pg_regress has code in it to limit the
> degree of parallelism of tests, and has done for years, specifically to
> cater for buildfarm machines that are unable to handle the defaults. Using
> this option in the buildfarm client config triggers use of this feature.

Hmm, I wasn't aware of that.  I thought they needed 20 connections
because parallel_schedule says:

# By convention, we put no more than twenty tests in any one parallel group;
# this limits the number of connections needed to run the tests.

If it's not supposed to matter how many connections are available,
then that comment is misleading.  But I think it does matter, at least
in some situations, because otherwise these machines wouldn't be
failing with "sorry, too many clients already".

Anyway, as Andres said, the machines were working fine until recently,
so I think we just need to get them un-broken.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: buildfarm failures on smew and anole
Next
From: Andres Freund
Date:
Subject: Re: buildfarm failures on smew and anole