Robert Haas <robertmhaas@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
