Horton

Thread

  1. remove checkpoint_warning

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2016-07-09T20:46:32Z

    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.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

  2. Re: remove checkpoint_warning

    Andres Freund <andres@anarazel.de> — 2016-07-09T20:59:45Z

    On 2016-07-09 16:46:32 -0400, Alvaro Herrera wrote:
> 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.

I think we could do that, if we enable log_checkpoints by default, but
right now we don't...

  3. Re: remove checkpoint_warning

    Tom Lane <tgl@sss.pgh.pa.us> — 2016-07-09T21:12:15Z

    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

  4. Re: remove checkpoint_warning

    Stephen Frost <sfrost@snowman.net> — 2016-07-11T14:25:13Z

    * Tom Lane (tgl@sss.pgh.pa.us) 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.

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.

Thanks!

Stephen

  5. Re: remove checkpoint_warning

    Peter Geoghegan <pg@heroku.com> — 2016-07-11T18:14:29Z

    On Mon, Jul 11, 2016 at 7:25 AM, Stephen Frost <sfrost@snowman.net> wrote:
>> 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.

I agree. checkpoint_warning exists for the benefit of novice DBAs.
I've seen those warnings in customer logs on several occasions, at
least back when I was a consultant.

-- 
Peter Geoghegan

  6. Re: remove checkpoint_warning

    Andres Freund <andres@anarazel.de> — 2016-07-11T18:20:38Z

    On 2016-07-11 11:14:29 -0700, Peter Geoghegan wrote:
> On Mon, Jul 11, 2016 at 7:25 AM, Stephen Frost <sfrost@snowman.net> wrote:
> >> 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.
> 
> I agree. checkpoint_warning exists for the benefit of novice DBAs.
> I've seen those warnings in customer logs on several occasions, at
> least back when I was a consultant.

Note that the situation changed a bit with 9.5, because our defaults
aren't absurdly conservative (checkpoint_segments = 3) anymore.

  7. Re: remove checkpoint_warning

    Stephen Frost <sfrost@snowman.net> — 2016-07-11T21:54:28Z

    * Andres Freund (andres@anarazel.de) wrote:
> On 2016-07-11 11:14:29 -0700, Peter Geoghegan wrote:
> > On Mon, Jul 11, 2016 at 7:25 AM, Stephen Frost <sfrost@snowman.net> wrote:
> > >> 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.
> > 
> > I agree. checkpoint_warning exists for the benefit of novice DBAs.
> > I've seen those warnings in customer logs on several occasions, at
> > least back when I was a consultant.
> 
> Note that the situation changed a bit with 9.5, because our defaults
> aren't absurdly conservative (checkpoint_segments = 3) anymore.

Agreed, but I don't think that means we'll never see that warning
again..

Thanks!

Stephen

  8. Re: remove checkpoint_warning

    Craig Ringer <craig@2ndquadrant.com> — 2016-07-12T01:32:18Z

    On 11 July 2016 at 22:25, Stephen Frost <sfrost@snowman.net> wrote:

> * Tom Lane (tgl@sss.pgh.pa.us) 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.
>
> 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.



-- 
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

  9. Re: remove checkpoint_warning

    Magnus Hagander <magnus@hagander.net> — 2016-07-12T08:19:48Z

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

> On 11 July 2016 at 22:25, Stephen Frost <sfrost@snowman.net> wrote:
>
>> * Tom Lane (tgl@sss.pgh.pa.us) 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.
>>
>> 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/

  10. Re: remove checkpoint_warning

    Hans-Jürgen Schönig <postgres@cybertec.at> — 2016-07-12T10:46:25Z

    
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

  11. Re: remove checkpoint_warning

    Robert Haas <robertmhaas@gmail.com> — 2016-07-13T20:03:49Z

    On Tue, Jul 12, 2016 at 3:19 AM, Magnus Hagander <magnus@hagander.net> wrote:
> +1, this is a useful warning.

+1.

I'd like to see more people turn log_checkpoints=on, and I often ask
customers to do that when they're having systemic performance
problems.  But this warning regularly alerts me to cases where I've
failed to configure max_wal_size to an adequately large value.  It's
true that the new values are less conservative than the old ones, but
they're still pretty conservative.  Anybody who still thinks that 1GB
is a lot of disk space might be due for a hardware upgrade.  I
regularly need to increase that value substantially on my *laptop*.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company