On Friday 04 April 2008 01:59, Tom Lane wrote:
> Greg Smith <gsmith@gregsmith.com> writes:
> > On Thu, 3 Apr 2008, Tom Lane wrote:
> >> I'd much rather be spending our time and effort on understanding what
> >> broke for you, and fixing the code so it doesn't happen again.
> >
> > [ shit happens... ]
>
> Completely fair, but I still don't see how this particular patch would
> be a useful addition to the DBA's monitoring-tool arsenal. The scope
> seems too narrow.
>
So, thinking about this for a few minutes, here are some of the things that
knowing the last checkpoint time might help a DBA determine.
1) Alert if checkpointing stops occuring within a reasonable time frame (note
there are failure cases and normal use cases where this might occur) (also
note I'll agree, this isn't common, but the results are pretty disatrous if
it does happen)
2) Can be graphed over time (using rrdtool and others) for trending checkpoint
activity
3) Ease monitoring of checkpoints across pitr setups
4) Help determine if your checkpoints are being timeout driven or segment
driven, or if you need to look at those settings
5) Determine the number of log files that will need to be replayed in the
event of a crash
6) Helps give an indication on if you should enter a manual checkpoint before
issuing a pg_start_backup call
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
