[check_postgres] [Check_postgres-commit] [commit] Add comment clarifying the value measured by the 'checkpoint' action
Greg Sabino Mullane
greg at endpoint.com
Sat Jan 8 02:40:27 UTC 2011
(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
More information about the Check_postgres
mailing list