On 07/09/2016 11:12 PM, Tom Lane wrote:
Alvaro Herrera <alvhe...@2ndquadrant.com> writes:
the checkpoint_warning feature was added by commit 2986aa6a668bce3cfb836
in November 2002 when we didn't have any logging of checkpointing at
all. I propose to remove it: surely anyone who cares about analyzing
checkpointing behavior nowadays is using the log_checkpoint feature
instead, which contains much more detail. The other one is just noise
now, and probably ignored amidst the number of other warning traffic.
Hmm, not sure. ISTM log_checkpoint is oriented to people who know what
they are doing, whereas checkpoint_warning is more targeted to trying
to help people who don't. Perhaps you could make an argument that
checkpoint_warning is useless because the people whom it's meant to help
won't notice the warning anyway --- but I doubt that it's been
"superseded" by log_checkpoint, because the latter would only be enabled
by people who already have a clue that checkpoint performance is something
to worry about.
Or in short, this may be a fine change to make, but I don't like your
argument for it.
regards, tom lane
i think tom is right here.
log_checkpoint and checkpoint_warning are for totally different people.
we might just want to do one thing: we might want to state explicitly
that the database cannot break down if this warning shows up.
many people are scared to death that this warning somehow indicates that
PostgreSQL is about to go up in flames, which is of course not true.
maybe we could do "consider increasing .... to ensure good performance"
or so ...
regards,
hans
--
Hans-Jürgen Schönig
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de, http://www.cybertec.at
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
