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.
        regards, tom lane