Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> There is no difference. If anything bad happens with the current
>> multi-process server, all the postgres backends shutdown because the
>> shared memory may be corrupted.
> Yes. Are we adding reliability with per-process backends.
Yes, we are: the postmaster forces a system-wide restart only if a
backend actually coredumps, or exits with elog(STOP). If a backend
curls up and dies with elog(FATAL), we assume it's a positive sign
that it was able to detect the error ;-), and keep plugging.
Now you might argue about whether any particular error case has been
misclassified, and I'm sure some are. But my point is that in a
multithread environment we couldn't risk allowing the other threads to
keep running after an elog(FATAL), either. Threads don't have *any*
protection against screwups in other threads.
A closely related point: how often do you hear of postmaster crashes?
They don't happen, as a rule. That's because the postmaster is (a)
simple and (b) decoupled from the backends. To convert backend process
launch into backend thread launch, the postmaster would have to live
in the same process space as the backends, and that means any backend
coredump would take down the postmaster too.
regards, tom lane