On Thu, Mar 10, 2011 at 2:42 PM, Dimitri Fontaine <dimi...@2ndquadrant.fr> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> was. So you could then say things like "is the most recent time at >> which the standby was caught up within the last 30 seconds?", which >> would be a useful thing to monitor, and right now there's no way to do > > Well in my experience with replication, that's not what I want to > monitor. If the standby is synchronous, then it's not catching up, it's > streaming. If it were not, it would not be a synchronous standby. > > When a standby is asynchronous then what I want to monitor is its lag. > > So the CATCHUP state is useful to see that a synchronous standby > candidate can not yet be a synchronous standby. When it just lost its > synchronous status (and hopefully another standby is now the sync one), > then it's just asynchronous and I want to know its lag.
Yeah, maybe. The trick is how to measure the lag. I proposed the above scheme mostly as a way of giving the user some piece of information that can be measured in seconds rather than WAL position, but I'm open to better ideas. Monitoring is pretty hard to do at all in 9.0; in 9.1, we'll be able to tell them how many *bytes* behind they are, but there's no easy way to figure out what that means in terms of wall-clock time, which I think would be useful. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
