Skip site navigation (1) Skip section navigation (2)

Re: Streaming replication status

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 (view raw or flat)
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


In response to

Responses

pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2010-01-15 18:50:26
Subject: Re: Hot Standby and handling max_standby_delay
Previous:From: Simon RiggsDate: 2010-01-15 18:39:20
Subject: Re: Streaming replication, loose ends

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group