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,
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.
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
* the requested number of backends. We used to allocate
* only when backends were actually started up, but that is bad
* it lets Postgres fail under load --- a lot of Unix systems are
* (mis)configured with small limits on the number of semaphores,
* running out when trying to start another backend is a common
* So, now we grab enough semaphores to support the desired max
* of backends immediately at initialization --- if the sysadmin
* MaxBackends higher than his kernel will support, he'll find
* rather than later.
* Another reason for creating semaphores here is that the
* implementation typically requires us to create semaphores in
* postmaster, not in backends.
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]