Re: Streaming replication status
Robert Treat <xzilla@users.sourceforge.net>
From: Robert Treat <xzilla@users.sourceforge.net>
To: pgsql-hackers@postgresql.org
Cc: Greg Smith <greg@2ndquadrant.com>, Fujii Masao <masao.fujii@gmail.com>, Craig Ringer <craig@postnewspapers.com.au>, Josh Berkus <josh@agliodbs.com>, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Date: 2010-01-13T01:44:48Z
Lists: pgsql-hackers
On Monday 11 January 2010 23:24:24 Greg Smith wrote: > Fujii Masao wrote: > > On Mon, Jan 11, 2010 at 5:36 PM, Craig Ringer > > > > <craig@postnewspapers.com.au> wrote: > >> Personally, I'd be uncomfortable enabling something like that without > >> _both_ an admin alert _and_ the ability to refresh the slave's base > >> backup without admin intervention. > > > > What feature do you specifically need as an alert? Just writing > > the warning into the logfile is enough? Or need to notify by > > using SNMP trap message? Though I'm not sure if this is a role > > of Postgres. > > It's impossible for the database to have any idea whatsoever how people > are going to want to be alerted. Provide functions to monitor things > like replication lag, like the number of segments queued up to feed to > archive_command, and let people build their own alerting mechanism for > now. They're going to do that anyway, so why waste precious time here > building someone that's unlikely to fit any but a very narrow use case? That said, emitting the information to a log file makes for a crappy way to retrieve the information. The ideal api is that I can find the information out via result of some SELECT query; view, table ,function doesn't matter, as long as I can select it out. Bonus points for being able to get information from the hot standby. -- Robert Treat Conjecture: http://www.xzilla.net Consulting: http://www.omniti.com