Re: checkpoints are duplicated even while the system is idle
Kevin Grittner <kevin.grittner@wicourts.gov>
From: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
To: "Robert Haas" <robertmhaas@gmail.com>, "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Simon Riggs" <simon@2ndquadrant.com>, "Fujii Masao" <masao.fujii@gmail.com>, "PostgreSQL-development" <pgsql-hackers@postgresql.org>
Date: 2011-10-06T17:26:56Z
Lists: pgsql-hackers
Robert Haas <robertmhaas@gmail.com> wrote: > Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I think the point is that a totally idle database should not >> continue to emit WAL, not even at a slow rate. There are also >> power-consumption objections to allowing the checkpoint process >> to fire up to no purpose. > > Hmm, OK. I still think it's a little funny to say that > checkpoint_timeout will force a checkpoint every N minutes except > when it doesn't, but maybe there's no real harm in that as long as > we document it properly. What will be the best way to determine, from looking only at a standby, whether replication is healthy and progressing? Going back to the 8.1 warm standby days we have run pg_controldata and compared the "Time of latest checkpoint" to current time; I'm hoping there's a better way now, so that we can drop that kludge. If not, I would like a way to kick out a checkpoint from the master at some finite and configurable interval for monitoring purposes. I'm all for having a nice, sharp fillet knife, but if that's not available, please don't take away this rock I chipped at until it had an edge. Most likely there's something there which I've missed, but it's really nice to be able to tell the difference between a quiet master and broken replication. -Kevin