MauMau <maumau307@gmail.com> wrote:
> From: "Greg Stark" <stark@mit.edu>
>> On the client end the FATAL is pretty logical but in the logs it
>> makes it sound like the entire server died.
I agree that is easily misunderstood, especially since a FATAL
problem is less severe than a PANIC; while in common English usage
panic is what might feel when faced with the prospect of speaking
in public, but fatal generally means something that kills -- like a
disease or a plane crash. There is the notion of a "fatal error"
in English, though; which means an error which puts an end to what
the person who makes such an error is attempting.
>> FATAL is a term of art peculiar to Postgres.
No, it is not; at least not in terms of being "characteristic of
only one person, group, or thing". The Java logger from Apache
called log4j has a FATAL level which is more serious than ERROR.
The distinction is intended to indicate whether the application is
likely to be able to continue running. Similarly, Sybase ASE has
severity levels, where above a certain point they are described as
"fatal" -- meaning that the application must acquire a new
connection. It's probably used elsewhere as well; those are just a
couple I happened to be familiar with.
> I find it unnatural for a normal administration operation to emit
> a FATAL message.
It seems to be a fairly common term of art for a problem which
requires a restart or reconnection. FATAL is used when the problem
is severe enough that the process or connection must end. It seems
to me to be what should consistently be used when a client
connection or its process must be terminated for a reason other
than a client-side request to terminate.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
