Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> But it isn't the same. If all backends FATAL'ed at once, that wouldn't
>> provoke the postmaster to wipe shared memory and run a WAL recovery
>> cycle.
> I called it FATALALL because the effect is to have all backends
> FATALly terminate.
But my point was that that's a very inadequate description of what it
does. Peter's insisting on precision in the names, so let's not pick
names that appear to mean something exact and are misleading about it.
>> What do you think of Karl's suggestion of PANIC?
> That is good too. The FATAL becomes like a process segfault, and PANIC
> is like a kernel panic.
Yeah, the more I think about it the more I like PANIC. There's really
a fairly good analogy to kernel panics: it's a forced system-wide
restart with ensuing recovery activity (WAL replay ~= fsck).
BTW, a more radical proposal would be to get rid of FATAL in its current
form altogether. FATAL essentially says "okay, this backend is so
screwed up that it can't possibly continue, but I'm certain we didn't
mess up shared memory". Now, how certain can you *really* be of that,
if you also believe that you can't recover the current backend?
Most of the existing uses of FATAL seem to be out-of-memory errors
(which these days ought not be considered FATAL), or startup errors
(which would more reasonably be handled by saying that ERROR before
we reach the main loop causes backend exit). There might be a small
number of places where it's really legitimate, but I think not very
many.
However, even if we did retire the current meaning of FATAL, I'd not
want to reassign it to STOP/PANIC/whatever; too much potential for
confusion if we do. So we need a new name for STOP anyway.
regards, tom lane
