Re: Fix checkpoint skip logic on idle systems by tracking LSN progress
От | Kyotaro HORIGUCHI |
---|---|
Тема | Re: Fix checkpoint skip logic on idle systems by tracking LSN progress |
Дата | |
Msg-id | 20161111.165448.169244829.horiguchi.kyotaro@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: Fix checkpoint skip logic on idle systems by tracking LSN progress (Michael Paquier <michael.paquier@gmail.com>) |
Список | pgsql-hackers |
Thank you for the new patch. At Fri, 11 Nov 2016 16:42:43 +0900, Michael Paquier <michael.paquier@gmail.com> wrote in <CAB7nPqR73vusv5kQgZzket5mLZLeEcgNF-3hKh7061QtcZiuVw@mail.gmail.com> > On Fri, Nov 11, 2016 at 12:28 AM, Stephen Frost <sfrost@snowman.net> wrote: > > We should probably include in here that we may skip a checkpoint if no > > activity has happened, meaning that this is a safe setting to set for > > environments which are idle for long periods. > > OK, here is the interesting bit I just updated (I cut the diff a bit > as the rest is just reformatting): > parameter is greater than zero, the server will switch to a new > segment file whenever this many seconds have elapsed since the last > segment file switch, and there has been any database activity, > - including a single checkpoint. (Increasing > - <varname>checkpoint_timeout</> will reduce unnecessary > - checkpoints on an idle system.) > [...] > + including a single checkpoint. Checkpoints can however be skipped > + if there is no database activity, making this parameter a safe > + setting for environments which are idle for a long period of time. > > > (I'm thinking embedded systems here). > > (Those are most of my users :{) ). Ok, (FWIW..,) it seems fine for me. > On Fri, Nov 11, 2016 at 3:23 AM, David Steele <david@pgmasters.net> wrote: > > On 11/10/16 1:03 PM, Stephen Frost wrote: > >> Agreed. You certainly may wish to log checkpoints, even on an embedded > >> or low I/o system, but logging that nothing is happening doesn't seem > >> useful except perhaps for debugging. > > > > Sure, DEBUG1 or DEBUG2 makes sense. > > OK. LOG was useful to avoid noise when debugging the thing, but DEBUG1 > is fine for me as well in the final version. Agreed. DEBUG2 seems too deep for it. Well, I think we had the final comment and it has been addressd so I mark this as ready for committer soon. Thank you all. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: