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

"Oliver Elphick" <olly(at)lfix(dot)co(dot)uk> writes:
> The major problem at the moment is not that a new backend fails, but
> that it brings down everything else with it.

Agreed.

> How about having a new backend set a one-byte flag in shared memory
> when it has finished setting itself up? as long as the flag is unset,
> the backend is still starting itself up, and a failure will not
> require other backends to be brought down.

Not much win to be had there, I suspect. The main problem is that as
soon as a new backend starts altering shared memory, you have potential
corruption issues to worry about if it goes down. And there's not
really very much the new backend can do before it alters shared memory.
In fact, it can't do much of *anything* until it's made an entry for
itself in the lock manager's PROC array, because it cannot find out
anything interesting without locking shared structures.

Hmm. If that's true, then the failure to get a sema would occur very
early in the new backend's lifetime, before it's had a chance to create
any trouble. Maybe the very easiest solution to the sema issue is to
make the new backend send a failure report to its client and then
exit(0) instead of exit(1), so that the postmaster considers it a clean
exit rather than a crash...

regards, tom lane