The Hermit Hacker wrote:
>
> On Thu, 25 Feb 1999, Tom Lane wrote:
>
> > 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?
>
<snip comment on undocumented solaris call>
Perhaps on startup the postmaster can allocate the max number of
semaphores, thus preserving the 'fail now, not later' behavior, but then
release all but a smaller block? (say, 16)? Kind of an amalgam of the
new and old allocation strategies. that way, other programs that
potentially need a large number of sems can have them, if postgresql
isn't using them right now, without needing a reconfigured kernel.
Hmm, that does open a window for failure if there are sufficient sems at
startup, but not latter, when the high load kicks in. Perhaps a
configuration flag, for "greedy semaphore allocation?" This lets the
DBA decide what should fail under the high load, scarce sems condition.
If the db is mission critical, it's worth reconfiguring, and letting it
have all the sems. Even if "non-greedy", still do the test, and fail if
there's not enough potential sems for a max num of backends, though
(don't plan the timebomb, basically).
Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005