MauMau wrote > From: "David Johnston" < > polobo@
> > >>> 5. FATAL: terminating walreceiver process due to administrator command >>> 6. FATAL: terminating background worker \"%s\" due to administrator >>> command >> 5 and 6: I don't fully understand when they would happen but likely fall >> into the same "the DBA should know what is going on with their server and >> confirm any startup/shutdown activity it is involved with". >> >> They might be better categorized "NOTICE" level if they were in response >> to >> a administrator action, versus in response to a crashed process, but even >> for the user-initiated situation making sure they hit the log but using >> FATAL is totally understandable and IMO desirable. > > #5 is output when the DBA shuts down the replication standby server. > #6 is output when the DBA shuts down the server if he is using any custom > background worker. > These messages are always output. What I'm seeing as a problem is that > FATAL messages are output in a normal situation, which worries the DBA, > and > those messages don't help the DBA with anything. They merely worry the > DBA. While "worry" is something to be avoided not logging messages is not the correct solution. On the project side looking for ways and places to better communicate to the user is worthwhile in the absence of adding additional complexity to the logging system. The user/DBA, though, is expected to learn how the proces works, ideally in a testing environment where worry is much less a problem, and understand that some of what they are seeing are client-oriented messages that they should be aware of but that do not indicate server-level issues by themselves. They should probably run the log through a filter (a template of which the project should provide) that takes the raw log and filters out those things that, relative to the role and context, are really better classified as NOTICE even if the log-level is shown as FATAL. Raw logs should be verbose so that tools can have more data with which to make decisions. You can always hide what is provided but you can never show was has been omitted. I get that people wil scan raw logs but targeting that lowest-denominator isn't necessarily the best thing to do. Instead, getting those people on board with better practices and showing (and providing) them helpful tools should be the goal. David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/RFC-Shouldn-t-we-remove-annoying-FATAL-messages-from-server-log-tp5781899p5782267.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
