On Wed, Sep 22, 2010 at 8:12 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
Not speaking to the necessity of standby registration, but...
>> Thinking of this as a sysadmin, what I want is to have *one place* I can
>> go an troubleshoot my standby setup. If I have 12 synch standbys and
>> they're creating too much load on the master, and I want to change half
>> of them to async, I don't want to have to ssh into 6 different machines
>> to do so. If one standby needs to be taken out of the network because
>> it's too slow, I want to be able to log in to the master and instantly
>> identify which standby is lagging and remove it there.
>
> The above case is one where I can see your point and it does sound
> easier in that case. But I then think: "What happens after failover?".
> We would then need to have 12 different standby.conf files, one on each
> standby that describes what the setup would look like if that standby
> became the master. And guess what, every time we made a change on the
> master, you'd need to re-edit all 12 standby.conf files to reflect the
> new configuration. So we're still back to having to edit in multiple
> places, ISTM.
An interesting option here might be to have "replication.conf"
(instead of standby.conf) which would list all servers, and a
postgresql.conf setting which would set the "local name" the master
would then ignore. Then all PG servers (master+slave) would be able
to have identical replication.conf files, only having to know their
own "name". Their own name could be GUC, from postgresql.conf, or
from command line options, or default to hostname, whatever.