True, but even so, 32 max connections is a bit light. I have more
pgsql databases than that on my box now. My point in my previous answer
to Tom was that you HAVE to shut down postgresql to change this. It
doesn't allocate tons of semaphores on startup,
[snip]
is this correct? I recall looking through the source and seeing
comments to the affect that it is better to allocate them all
(semaphores) up front in order to prevent runtime failed allocations.
(could be totally off base on this).
You don't have to be using apache to need more than 32 simo connections.
Heck, how many postgresql databases do you figure are in production with
that setting still in there? My guess is not many.
[snip]
True, and it is not unheard of to put minimum specs for version x of the
database, i.e. 7.4 requires kernel 2.x and so on.
Here's the comment I was referring to:
/*
* InitProcGlobal -
*initializes the global process table. We put it here so that
*the postmaster can do this initialization.
*
*We also create all the per-process semaphores we will need to
support
*the requested number of backends. We used to allocate
semaphores
*only when backends were actually started up, but that is bad
because
*it lets Postgres fail under load --- a lot of Unix systems are
*(mis)configured with small limits on the number of semaphores,
and
*running out when trying to start another backend is a common
failure.
*So, now we grab enough semaphores to support the desired max
number
*of backends immediately at initialization --- if the sysadmin
has set
*MaxBackends higher than his kernel will support, he'll find
out sooner
*rather than later.
*
*Another reason for creating semaphores here is that the
semaphore
*implementation typically requires us to create semaphores in
the
*postmaster, not in backends.
*/
Merlin
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
