Re: system views for walsender activity

From: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
To: Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndQuadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: system views for walsender activity
Date: 2010-06-22 07:54:16
Message-ID: 4C206C28.2010100@lelarge.info
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Le 22/06/2010 06:40, Takahiro Itagaki a écrit :
> [...]
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> I'm of the opinion that this is a 9.1 problem. It needs more thought
>> than we can put into it now --- one obvious question is what about
>> monitoring on the slave side? Another is who should be able to see the
>> data?
>
> Sure. We should research user's demands for monitoring and management
> of replication. I'll report some voices from users as of this moment:
>
> * Managers often ask DBAs "How long standby servers are behind the master?"
> We should provide such methods for DBAs. We have pg_xlog_location()
> functions, but they should be improved for:
> - The returned values are "xxx/yyy" texts, but more useful information
> is the difference of two values. Subtraction functions are required.
> - For easier management, the master server should provide not only
> sent/flush locations but also received/replayed locations for each
> standby servers. Users don't want to access both master and slaves.
>
> * Some developers want to pause and restart replication from the master
> server. They're going to use replication for application version
> managements. They'll pause all replications, and test their new features
> at the master, and restart replication to spread the changes to slaves.
>

I agree on these two.

Something I found lacking when I added support for Hot Standby /
Streaming Replication in pgAdmin (that was a really small patch, there
was not a lot to do) was that one cannot get the actual value of each
recovery.conf parameter. Try a "SHOW primary_conninfo;" and it will
juste reply that primary_conninfo is an unknown parameter. I already
talked about this to Heikki, but didn't get a chance to actually look at
the code.

--
Guillaume
http://www.postgresql.fr
http://dalibo.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2010-06-22 08:34:38 Re: Explicit psqlrc
Previous Message Bruce Momjian 2010-06-22 05:06:26 Re: pg_upgrade issues