From: | Greg Smith <greg(at)2ndquadrant(dot)com> |
---|---|
To: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> |
Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, 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-15 18:44:18 |
Message-ID: | 4B50B782.40805@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stefan Kaltenbrunner wrote:
>>
>> Another popular question is "how far behind real-time is the archiver
>> process?" You can do this right now by duplicating the same xlog
>> file name scanning and sorting that the archiver does in your own
>> code, looking for .ready files. It would be simpler if you could
>> call pg_last_archived_xlogfile() and then just grab that file's
>> timestamp.
>
> well that one seems a more reasonable reasoning to me however I'm not
> so sure that the proposed implementation feels right - though can't
> come up with a better suggestion for now.
That's basically where I'm at, and I was looking more for feedback on
that topic rather than to get lost defending use-cases here. There are
a few of them, and you can debate their individual merits all day. As a
general comment to your line of criticism here, I feel the idea that
"we're monitoring that already via <x>" does not mean that an additional
check is without value. The kind of people who like redundancy in their
database like it in their monitoring, too. I feel there's at least one
unique thing exposing this bit buys you, and the fact that it can be a
useful secondary source of information too for systems monitoring is
welcome bonus--regardless of whether good practice already supplies a
primary one.
> If you continue your line of thought you will have to add all kind of
> stuff to the database, like CPU usage tracking, getting information
> about running processes, storage health.
I'm looking to expose something that only the database knows for
sure--"what is the archiver working on?"--via the standard way you ask
the database questions, a SELECT call. The database doesn't know
anything about the CPU, running processes, or storage, so suggesting
this path leads in that direction doesn't make any sense.
--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.com
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2010-01-15 18:50:26 | Re: Hot Standby and handling max_standby_delay |
Previous Message | Simon Riggs | 2010-01-15 18:39:20 | Re: Streaming replication, loose ends |