On 23/09/10 12:49, Dimitri Fontaine wrote:
Heikki Linnakangas<heikki.linnakan...@enterprisedb.com> writes:
The consensus seems to be use a configuration file called
standby.conf. Let's use the "ini file format" for now [1].
What about automatic registration of standbys? That's not going to fly
with the unique global configuration file idea, but that's good news.
Automatic registration is a good answer to both your points A)
monitoring and C) wal_keep_segments, but needs some more thinking wrt
security and authentication.
What about having a new GRANT privilege for replication, so that any
standby can connect with a non-superuser role as soon as the master's
setup GRANTS replication to the role? You still need HBA setup to be
accepting the slave, too, of course.
There's two separate concepts here:
1. Automatic registration. When a standby connects, its information gets
permanently added to standby.conf file
2. Unregistered standbys. A standby connects, and its information is not
in standby.conf. It's let in anyway, and standby.conf is unchanged.
We'll need to support unregistered standbys, at least in asynchronous
mode. It's also possible for synchronous standbys, but you can't have
the "if the standby is disconnected, don't finish any commits until it
reconnects and catches up" behavior without registration.
I'm inclined to not do automatic registration, not for now at least.
Registering a synchronous standby should not be taken lightly. If the
standby gets accidentally added to standby.conf, the master will have to
keep more WAL around and might delay all commits, depending on the
options used.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
