On Tue, Oct 3, 2017 at 12:01 AM, Stephen Frost <sfr...@snowman.net> wrote: > I certainly don't care for the idea of adding log messages saying we > aren't doing anything just to match a count that's incorrectly claiming > that checkpoints are happening when they aren't. > > The down-thread suggestion of keeping track of skipped checkpoints might > be interesting, but I'm not entirely convinced it really is. We have > time to debate that, of course, but I don't really see how that's > helpful. At the moment, it seems like the suggestion to add that column > is based on the assumption that we're going to start logging skipped > checkpoints and having that column would allow us to match up the count > between the new column and the "skipped checkpoint" messages in the logs > and I can not help but feel that this is a ridiculous amount of effort > being put into the analysis of something that *didn't* happen.
Being able to look at how many checkpoints are skipped can be used as a tuning indicator of max_wal_size and checkpoint_timeout, or in short increase them if those remain idle. Since their introduction in 335feca4, m_timed_checkpoints and m_requested_checkpoints track the number of checkpoint requests, not if a checkpoint has been actually executed or not, I am not sure that this should be changed after 10 years. So, to put it in other words, wouldn't we want a way to track checkpoints that are *executed*, meaning that we could increment a counter after doing the skip checks in CreateRestartPoint() and CreateCheckPoint()? -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers