On Thu, 25 Feb 1999, Tom Lane wrote:
> Tom Ivar Helbekkmo <tih@nhh.no> writes:
> > Looking more closely into it, the postmaster is trying to allocate 64
> > semaphores in four groups of 16, so I built a new kernel with a higher
> > limit, and it's now OK.
> > This is as it should be, I hope? It's not a case of something being
> > misconfigured now, using semaphores instead of some other facility?
>
> Yes, this is an intentional change --- I guess you haven't been reading
> the hackers list very closely. The postmaster is now set up to grab
> all the semaphores Postgres could need (for the specified number of
> backend processes) immediately at postmaster startup. Failing then
> for lack of semaphores seems a better idea than failing under load
> when you try to start the N+1'st client, which is what used to happen.
>
> There has been some discussion of reducing the default number-of-
> backends limit to 32 so that a stock installation is less likely
> to run out of semaphores.
Is there any way (sysctl?) of determining the max # of semaphores
configured into a system?
I just looked at a sys/sysconfig.h under Solaris, and it appears they have
an "undocumented function" that does this...but I can't seem to find
anything right off...
For that matter, being able to do a configure check to see if semaphores
are even compiled into the system or not (ala FreeBSD) might be nice
too...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org