Hi all,
Some time ago I was also interested in this feature, and that time I
also thought about complete setup possibility via postgres connections,
meaning the transfer of the files and all configuration/slave
registration to be done through normal backend connections.
In the meantime our DBs are not able to keep in sync via WAL
replication, that would need some kind of parallel WAL restore on the
slave I guess, or I'm not able to configure it properly - in any case
now we use slony which is working. In fact the way slony is doing the
configuration could be a good place to look...
On Wed, 2010-09-22 at 13:16 -0400, Robert Haas wrote:
> > I guarantee you there is a way around the cascade slave problem.
>
> And that would be...?
* restrict the local file configuration to a replication ID;
* make all configuration refer to the replica ID;
* keep all configuration in a shared catalog: it can be kept exactly
the same on all replicas, as each replication "node" will only care
about the configuration concerning it's own replica ID;
* added advantage: after take-over the slave will change the configured
master to it's own replica ID, and if the old master would ever connect
again, it could easily notice that and give up;
Cheers,
Csaba.
