(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