On Tue, Jan 12, 2010 at 08:22, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > Greg Smith wrote: >> I don't think anybody can deploy this feature without at least some very >> basic monitoring here. I like the basic proposal you made back in >> September for adding a pg_standbys_xlog_location to replace what you >> have to get from ps right now: >> http://archives.postgresql.org/pgsql-hackers/2009-09/msg00889.php >> >> That's basic, but enough that people could get by for a V1. > > It would be more straightforward to have a function in the standby to > return the current replay location. It feels more logical to poll the > standby to get the status of the standby, instead of indirectly from the > master. Besides, the master won't know how far the standby is if the > connection to the standby is broken. > > Maybe we should just change the existing pg_current_xlog_location() > function to return that when recovery is in progress. It currently > throws an error during hot standby. >
Not sure. I don't really like to monitor functions that return different things depending on a scenario. Assume I monitor it, and then do a failover. Suddenly the values I monitor mean something else. I think I'd prefer a separate function to monitor this status on the slave. Oh, and it'd be nice if that one worked in HS mode both when in streaming and non-streaming mode :-) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
