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. > it. There's also a BACKUP state, but I'm not sure it makes sense to > lump that in with the others. Some day it might be possible to stream > WAL and take a backup at the same time, over the same connection. > Maybe that should be a separate column or something. BACKUP is still meaningful if you stream WAL at the same time, because you're certainly *not* applying them while doing the base backup, are you? So you're not yet a standby, that's what BACKUP means. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
