Le 22/06/2010 06:40, Takahiro Itagaki a écrit :
> [...]
> Tom Lane <t...@sss.pgh.pa.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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to