From: "David Johnston" <pol...@yahoo.com>
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.
I see, It might makes sense to make the DBA learn how the system works, so
that more DBAs can solve problems by themselves. However, I wonder how
those messages (just stopping server process by admin request) are useful
for the DBA. If they are useful, why don't other background processes (e.g.
archiver, writer, walsender, etc.) output such a message when stopping? For
information, #5 and #6 are not client-oriented.
If we want to keep the messages, I think LOG or DEBUG would be appropriate.
How about altering "ereport(FATAL, ...)" to "ereport(LOG, ...);
proc_exit(1)"?
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
