MauMau <maumau...@gmail.com> wrote: > From: "Greg Stark" <st...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers