Standby registration

(starting yet another thread to stay focused)

Having mulled through all the recent discussions on synchronous 
replication, ISTM there is pretty wide consensus that having a registry 
of all standbys in the master is a good idea. Even those who don't think 
it's *necessary* for synchronous replication seem to agree that it's 
nevertheless a pretty intuitive way to configure it. And it has some 
benefits even if we never get synchronous replication.

So let's put synchronous replication aside for now, and focus on standby 
registration first. Once we have that, the synchronous replication patch 
will be much smaller and easier to review.

The consensus seems to be use a configuration file called standby.conf. 
Let's use the "ini file format" for now [1].

Aside from synchronous replication, there are three nice things we can 
do with a standby registry:

A) Make monitoring easier. Let's have a system view to show the status 
of all standbys [2].

B) Improve authorization. At the moment, we require superuser rights to 
connect for connecting in replication mode. That's pretty ugly, because 
superuser rights imply that you can do anything; you'd typically want to 
restrict access from the standby to do replication only and nothing 
else. You can lock it down in pg_hba.conf to allow the superuser to only 
connect in replication mode, but it still gives me the creeps. When each 
standby has a name, we can associate standbys with roles, so that you 
have to be user X to replicate as standby Y.

C) Smarter replacement for wal_keep_segments. Instead of always keeping 
wal_keep_segments WAL files around, once we know how far each standby 
has replicated, we can keep just the right amount. I think we'll still 
want a global upper limit to avoid running out of disk space in the 
master in case of emergency though.


Any volunteers on implementing that? Fujii-san?

[1] http://archives.postgresql.org/pgsql-hackers/2010-09/msg01195.php
[2] http://archives.postgresql.org/pgsql-hackers/2010-09/msg00932.php

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com