Re: [RFC] Shouldn't we remove annoying FATAL messages from server log?
От | MauMau |
---|---|
Тема | Re: [RFC] Shouldn't we remove annoying FATAL messages from server log? |
Дата | |
Msg-id | 87C6B43A74ED462782A4AE08743BF833@maumau обсуждение исходный текст |
Ответ на | Re: [RFC] Shouldn't we remove annoying FATAL messages from server log? (Kevin Grittner <kgrittn@ymail.com>) |
Список | pgsql-hackers |
From: "Kevin Grittner" <kgrittn@ymail.com> > 5. FATAL: terminating walreceiver process due to administrator > command > 6. FATAL: terminating background worker \"%s\" due to > administrator command Those are client connections and their backends terminated for a reason other than the client side of the connection requesting it. If we don't classify those as FATAL then the definition of FATAL becomes much more fuzzy. What would you define it to mean? I'm sorry to cause you trouble, but my understanding is that those are not client connections. They are just background server processes; walreceiver is started by startup process, and background workers are started by extension modules. Am I misunderstanding something? According to Table 18-1 in the manual: http://www.postgresql.org/docs/current/static/runtime-config-logging.html the definition of FATAL is: FATAL Reports an error that caused the current session to abort. This does not apply to the above messages, because there is no error. The DBA just shut down the database server, and the background processes terminated successfully. If some message output is desired, LOG's definition seems the nearest: LOG Reports information of interest to administrators, e.g., checkpoint activity. So, I thought "ereport(LOG, ...); proc_exit(0)" is more appropriate than ereport(FATAL, ...). Is this so strange? Regards MauMau
В списке pgsql-hackers по дате отправления: