David Johnston wrote
>
> MauMau wrote
>> From: "Tom Lane" <
>> tgl@.pa
>> >
>>> There is no enthusiasm for a quick-hack solution here, and most people
>>> don't actually agree with your proposal that these errors should never
>>> get logged. So no, that is not happening. You can hack your local
>>> copy that way if you like of course, but it's not getting committed.
>>
>> Oh, I may have misunderstood your previous comments. I got the
>> impression
>> that you and others regard those messages (except "too many clients") as
>> unnecessary in server log.
>>
>> 1. FATAL: the database system is starting up
>> 2. FATAL: the database system is shutting down
>> 3. FATAL: the database system is in recovery mode
>>
>> 5. FATAL: terminating walreceiver process due to administrator command
>> 6. FATAL: terminating background worker \"%s\" due to administrator
>> command
>>
>> Could you tell me why these are necessary in server log? I guess like
>> this.
>> Am I correct?
>>
>> * #1 through #3 are necessary for the DBA to investigate and explain to
>> the
>> end user why he cannot connect to the database.
>>
>> * #4 and #5 are unnecessary for the DBA. I can't find out any reason why
>> these are useful for the DBA.
> For me 1-3 are unusual events in production situations and so knowing when
> they occur, and confirming they occurred for a good reason, is a key job
> of the DBA.
>
> 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.
>
> I'd ask in what situations are these messages occurring so frequently that
> they are becoming noise instead of useful data? Sorry if I missed your
> use-case explanation up-thread.
>
> David J.
Went and scanned the thread:
PITR/Failover is not generally that frequent an occurrence but I will agree
that these events are likely common during such.
Maybe PITR/Failover mode can output something in the logs to alleviate user
angst about these frequent events? I'm doubting that a totally separate
mechanism can be used for this "mode" but instead of looking for things to
remove how about adding some additional coddling to the logs and the
beginning and end of the mode change?
Thought provoking only as I have not actually been a user of said feature.
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/RFC-Shouldn-t-we-remove-annoying-FATAL-messages-from-server-log-tp5781899p5782235.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.