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@2ndQuadrant.com www.2ndQuadrant.com