Robert Treat wrote:
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)

What are the normal use cases where this would occur? I can't think of any.

Wrt. failure cases, there's a million things that can go wrong in a system, and only few of them will give the symptom of "checkpoints stopped happening", so I'm not excited about adding a facility to monitor just that.

More hooks for monitoring purposes in general would be nice, and I would like to see them exposed as SQL functions, but I'd like to see a much bigger proposal for that.

2) Can be graphed over time (using rrdtool and others) for trending checkpoint activity

Hmm. You'd need the historical data to do that properly. In particular, if two checkpoints happen between the polling interval, you'd miss that. log_checkpoints=on, in CSV output, seems like a better approach for that.

3) Ease monitoring of checkpoints across pitr setups

How is that different from monitoring in a non-pitr setup?

4) Help determine if your checkpoints are being timeout driven or segment driven, or if you need to look at those settings

Seems like the log_checkpoints output is more useful for that, as it directly tells you what triggered the checkpoint.

5) Determine the number of log files that will need to be replayed in the event of a crash

If you have a requirement for that, just set checkpoint_segments accordingly. And again, you can get the information in the logs by log_checkpoints=on already.

6) Helps give an indication on if you should enter a manual checkpoint before issuing a pg_start_backup call

If you want the backup to begin immediately, just do a manual checkpoint unconditionally. It'll finish quickly if there hasn't been much activity since the last one. We talked about adding a new variant of pg_start_backup() that does that automatically (or rather, just hurries the current checkpoint) in the 8.3 cycle, but didn't do it in the end. Perhaps we should add that, after all?

  Heikki Linnakangas

Sent via pgsql-patches mailing list (
To make changes to your subscription:

Reply via email to