On Friday 04 April 2008 01:59, Tom Lane wrote:
> Greg Smith <[EMAIL PROTECTED]> 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 

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

Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:

Reply via email to