Re: buildfarm failures on smew and anole

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>, CM Team <cm(at)enterprisedb(dot)com>
Subject: Re: buildfarm failures on smew and anole
Date: 2013-10-11 20:03:02
Message-ID: 52585976.4030501@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 10/11/2013 03:33 PM, Robert Haas wrote:
> The build is continuing to fail on smew and anole. The reason it's
> failing is because those machines are choosing max_connections = 10,
> which is not enough to run the regression tests. I think this is
> probably because of System V semaphore exhaustion. The machines are
> not choosing a small value for shared_buffers - they're still picking
> 128MB - so the problem is not the operating system's shared memory
> limit. But it might be that the operating system is short on some
> other resource that prevents starting up with a more normal value for
> max_connections. My best guess is System V semaphores; I think that
> one of the failed runs caused by the dynamic shared memory patch
> probably left a bunch of semaphores allocated, so the build will keep
> failing until those are manually cleaned up.
>
> Can the owners of these buildfarm machines please check whether there
> are extra semaphores allocated and if so free them? Or at least
> reboot, to see if that unbreaks the build?
>

It is possible to set the buildfarm config

build_env=> {MAX_CONNECTIONS => 10 },

and the tests will run with that constraint.

Not sure if this would help.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2013-10-11 20:05:35 Re: Cmpact commits and changeset extraction
Previous Message Bruce Momjian 2013-10-11 19:44:37 Re: [SQL] Comparison semantics of CHAR data type