Re: should we enable log_checkpoints out of the box? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: should we enable log_checkpoints out of the box?
Date
Msg-id CA+TgmoY=9GVpCmHgCNAJ6Rf1KrsouE6awKteAOE-MJ1PTp6qpg@mail.gmail.com
Whole thread Raw
In response to Re: should we enable log_checkpoints out of the box?  (Bruce Momjian <bruce@momjian.us>)
Responses Re: should we enable log_checkpoints out of the box?
Re: should we enable log_checkpoints out of the box?
List pgsql-hackers
On Tue, Nov 2, 2021 at 7:46 PM Bruce Momjian <bruce@momjian.us> wrote:
> I realize in this thread that Robert Haas mentioned foreign key
> violations that would like also appear in logs, but those are
> ERROR/WARNING etc. messages that can be filtered out with
> log_min_message.

I think that's pretty impractical. In order to get rid of all of the
harmless application errors, you'd have to set log_min_messages to
FATAL. That's a bad idea for two reasons. First, it wouldn't even
filter out all the garbage that you don't care about, and second, it
would filter out a lot of really important things that you do care
about. For example, you would still get messages in the logs like
"FATAL: connection to client lost" and "FATAL: canceling
authentication due to timeout" that probably nobody really cares
about, but you would not get messages like "ERROR: downlink or sibling
link points to deleted block in index <whatever>" which are indicative
of data corruption and thus important. For better or for worse, the
distinction between ERROR, FATAL, and PANIC is entirely based on what
we do after printing the message, and NOT on how serious the message
is.

Now maybe we want to improve that at some point, but it shouldn't
stand in the way of this proposal. If people are living with the
gigantic volume of ERROR and FATAL messages that typically end up in
the logs today, they can certainly live with the absolutely tiny
volume of additional information that would be generated by
log_checkpoints=on.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Schema variables - new implementation for Postgres 15
Next
From: Amul Sul
Date:
Subject: Re: removing global variable ThisTimeLineID