Re: Streaming replication status

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