From: | Greg Smith <greg(at)2ndquadrant(dot)com> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, Josh Berkus <josh(at)agliodbs(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Streaming replication status |
Date: | 2010-01-12 04:24:24 |
Message-ID: | 4B4BF978.3080602@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Fujii Masao wrote:
> On Mon, Jan 11, 2010 at 5:36 PM, Craig Ringer
> <craig(at)postnewspapers(dot)com(dot)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?
--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.com
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-01-12 04:44:30 | Re: damage control mode |
Previous Message | Greg Smith | 2010-01-12 04:21:29 | Re: Streaming replication status |