On 07/09/2016 11:12 PM, Tom Lane wrote:
> Alvaro Herrera <alvherre@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