Re: Fix checkpoint skip logic on idle systems by tracking LSN progress
От | David Steele |
---|---|
Тема | Re: Fix checkpoint skip logic on idle systems by tracking LSN progress |
Дата | |
Msg-id | a813eaf1-2d87-6914-9396-e740a5243898@pgmasters.net обсуждение исходный текст |
Ответ на | Re: Fix checkpoint skip logic on idle systems by tracking LSN progress (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: Fix checkpoint skip logic on idle systems by tracking
LSN progress
|
Список | pgsql-hackers |
On 11/10/16 1:03 PM, Stephen Frost wrote: > On Thursday, November 10, 2016, Joshua D. Drake <jd@commandprompt.com > <mailto:jd@commandprompt.com>> wrote: > > On 11/10/2016 09:33 AM, David Steele wrote: > > On 11/10/16 10:28 AM, Stephen Frost wrote: > > diff --git a/src/backend/access/transam/xlog.c > b/src/backend/access/transam/xlog.c > > [...] > > + if (log_checkpoints) > + ereport(LOG, > (errmsg("checkpoint skipped"))); > > > Do we really need to log that we're skipping a > checkpoint..? As the > point of this is to avoid write activity on a system which > is idle, it > doesn't make sense to me to add a new cause for writes to > happen when > we're idle. > > > log_checkpoints is not enabled by default, though, so if the > user does > enable it don't you think they would want to know when checkpoints > *don't* happen? > > > Yes but I don't know that it needs to be anywhere below DEBUG2 (vs > log_checkpoints). > > > 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. -- -David david@pgmasters.net
В списке pgsql-hackers по дате отправления: