Re: Streaming replication status

Greg Smith wrote:
> 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.

well that might be true - but as somebody with an extensive sysadmin
background I was specifically ticked by the "disk full" stuff mentioned
upthread. Monitoring also means standardization and somebody who runs
hundreds (or dozends) of servers is much better of getting the basics
monitored the same on all systems and getting more specific as you move
upwards the (application)stack.

>
>> 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.

well the database does not really know much about "free diskspace" in
reality as well - the only thing it knows is that it might not be able
to write data or execute a script and unless you have shell/logfile
access you cannot diagnose those anyway even with all the proposed
functions.
However what I was really trying to say is that we should focus on
getting the code stable first and that prettying it up with fancy stat
functions is something that really can and should be done in a followup
release once we understand how the code behaves and maybe also how it is
likely going to evolve...

Stefan