> 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
