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]
