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

Bruce Momjian <maillist@candle.pha.pa.us> writes:
>> A further thought: we could leave the semaphore management as-is,
>> and instead try to make running out of semaphores a less catastrophic
>> failure.

> 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.

That argument would be pretty convincing if pre-grabbing the semaphores
was sufficient to ensure we could start N backends, but of course it's
not sufficient.  The system could also run out of processes or file
descriptors, and I doubt that it's reasonable to grab all of those
instantly at postmaster startup.

The consensus seems clear not to go for the complex solution I described
at first.  But I'm still vacillating whether to do pre-reservation of
semaphores or just fix the postmaster to reject a connection cleanly if
no more can be gotten.  An advantage of the latter is that it would more
readily support on-the-fly changes of the max backend limit.  (Which I
am *not* proposing to support now; I only plan to make it settable at
postmaster startup; but someday we might want to change it on the fly.)
        regards, tom lane