[check_postgres] [Check_postgres-commit] [commit] Add comment clarifying the value measured by the 'checkpoint' action

[Greg Sabino Mullane]

(from a recent commit)

> ## Note that this value is actually the last checkpoint on the
> ## *master* (as copied from the WAL checkpoint record), so it more
> ## indicative that the master has been unable to complete a
> ## checkpoint for some other reason (i.e., unable to write dirty
> ## buffers or archive_command failure, etc).  As such, this check
> ## may make more sense on the master

No, that leaves out a whole raft of failure points for PITR.

> ## ...or we may want to look at
> ## the WAL segments received/processed instead of the checkpoint
> ## timestamp.

Yes, something like this might be feasible, but as I recently noted, 
it's hard to beat the ever-incrementing timestamp from pg_controldata. 
It tells us that the slave is up and properly reading the WAL. I'm 
not sure how one could even tell a WAL was successfully processed 
otherwise outside of log parsing.

-- 
Greg Sabino Mullane greg at endpoint.com
End Point Corporation
PGP Key: 0x14964AC8
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
Url : https://mail.endcrypt.com/pipermail/check_postgres/attachments/20110107/8fa8c1b8/attachment.bin