On Tue, Jul 12, 2016 at 3:32 AM, Craig Ringer <cr...@2ndquadrant.com> wrote:

> On 11 July 2016 at 22:25, Stephen Frost <sfr...@snowman.net> wrote:
>> * Tom Lane (t...@sss.pgh.pa.us) 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.
>> I don't agree that it's sensible to get rid of.  Having just
>> log_checkpoints will have the logs filled with checkpoints starting
>> because of XLOG, but there's no indication of that being a bad thing.
> Also, the warning is greppable-for and easily spotted by log ingesting
> tools. I see no real reason to remove it.

+1, this is a useful warning.

I'd flip the original argument over instead and say that for *most* people,
log_checkpoint output is mostly noise, and it's checkpoint_warnings that's
actually interesting. That on tells them if they have to look at anything
at all. It's true that those that care about *analyzing* their
checkpointing behaviour need to turn on log_checkpoint, but it's
checkpoint_warnings that tells them that they have to do this.

And the argument about it getting lost amongst other log traffic to me is
an argument for not turning on log_checkpoints by default. That generates a
lot of log entries that most people don't care for, and in doing so hides
other things in the log. It's excellent to have it once you need it, but it
shouldn't be turned on by default.

 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Reply via email to