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, Pennsylvania 19026