From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: remove checkpoint_warning |
Date: | 2016-07-12 01:32:18 |
Message-ID: | CAMsr+YFSY5-ymXRiSnp9kU_=_EfcLofpYBySkB7B7R-nFpO7KA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11 July 2016 at 22:25, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> > Alvaro Herrera <alvherre(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2016-07-12 01:34:00 | use of SEQ_MINVALUE in btree_gin |
Previous Message | Craig Ringer | 2016-07-12 01:13:12 | Re: Changing the result set to contain the cost of the optimizer's chosen plan |