-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 > I'm wondering if there's an accepted way to monitor a warm standby > machine's lag in 8.4. The wiki[1] has a link[2] to a script which > parses the output of pg_controldata, looking for a line like this: > > Time of latest checkpoint: Thu 09 Dec 2010 01:35:46 PM EST > > But I'm not sure whether this timestamp is to be trusted as an > indicator of how far behind the standby is in its recovery -- this > timestamp just tells us when the standby last performed a checkpoint, > regardless of how far behind in the WAL stream it is, right? Correct. But since we cannot connect to a database in recovery mode, there are very few options to determine how far 'behind' it is. The pg_controldata is what the check_postgres program uses. This offers a rough check which is usually sufficient unless you have a very inactive database or need very fine grained checking. A better system would perhaps connect to both ends and examine which specific WALs were being shipped and which one was last played, but there are no tools I know of that do that. I suspect the reason for this is that the pg_controldata check is "good enough". Certainly, that's what we are using for many clients via check_postgres, and it's been very good at detecting when the replica has problems. Good enough that I've never worried about writing a different method, anyway. :) - -- Greg Sabino Mullane greg@xxxxxxxxxxxx End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201012101126 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAk0CVN4ACgkQvJuQZxSWSshqIgCZASW1Tsf+8/Mk2qYPIzYUoYZz +CwAmwQbwzv8ED1QRskG8DavSr89NG/d =qwtc -----END PGP SIGNATURE----- -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general