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
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 |