Re: Standby registration

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