On 23/09/10 12:49, Dimitri Fontaine wrote:
> Heikki Linnakangas<heikki.linnakangas@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
