> I guess the slightly more ambitious performance monitoring bits that
> Simon was suggesting may cross the line as being too late to implement
> now though (depends on how productive the people actually coding on this
> are I guess), and certainly the ideas thrown out for implementing any
> smart behavior or alerting when replication goes bad like Josh's
> "archiving_lag_action" seem based the deadline to get addressed
> now--even though I agree with the basic idea.
Well, honestly, I wasn't talking about monitoring at all. I was talking
about the general issue of "how should the system behave when it runs
out of disk space".
For the installation for which data integrity is paramount, when
replication becomes impossible because there is no more room for logs,
then the whole system, master and slaves, should shut down. For most
people, they'd just want the master to start ignoring the slave and
recycling logs. Presumably, the slave would notice this and shut down.
So I was talking about data integrity, not monitoring.
However, it's probably a better thing to simply expose a way to query
how much extra log data we have, in raw form (bytes or pages). From
this, an administration script could take appropriate action.
--Josh Berkus