Re: Streaming replication status

Поиск
Список
Период
Сортировка
От Robert Treat
Тема Re: Streaming replication status
Дата
Msg-id 201001122044.48955.xzilla@users.sourceforge.net
обсуждение исходный текст
Ответ на Re: Streaming replication status  (Greg Smith <greg@2ndquadrant.com>)
Список 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Euler Taveira de Oliveira
Дата:
Сообщение: Re: Clearing global statistics
Следующее
От: Robert Treat
Дата:
Сообщение: Re: Streaming replication status