Re: [HACKERS] Re: Reducing sema usage (was Postmaster dies with many child processes)

> I said:
> > Any thoughts about which way to jump?  I'm sort of inclined to take
> > the simpler approach myself...
> 
> A further thought: we could leave the semaphore management as-is,
> and instead try to make running out of semaphores a less catastrophic
> failure.  I'm thinking that the postmaster could be the one to try
> to allocate more semaphores whenever there are none left, just before
> trying to fork a new backend.  (The postmaster has access to the same
> shared memory as the backends, right?  So no reason it couldn't do this.)
> If the allocation fails, it can simply refuse the connection request,
> rather than having to proceed as though we'd had a full-fledged backend
> crash.  This only works because we can predict the number of semas
> needed by an additional backend -- but we can: one.

If they asked for 64 backends, we better be able go give them to them,
and not crash or fail under a load.  64 semaphores is nothing.

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026