buildfarm failures on smew and anole

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: "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: buildfarm failures on smew and anole
Date: 2013-10-11 19:33:21
Message-ID: CA+TgmoYHiiGrcvSSJhmbSEBMoF2zX_9_9rWd75Cwvu99YrDxew@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

Thanks,

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2013-10-11 19:44:37 Re: [SQL] Comparison semantics of CHAR data type
Previous Message Pavel Stehule 2013-10-11 19:30:32 Re: proposal: simple date constructor from numeric values