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: (view raw, whole thread or download thread mbox)
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

In response to


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-2017 The PostgreSQL Global Development Group