David Parker wrote:

>If I have two slony clusters, and I want to establish a subscriber relationship between a node in one cluster and a node in the other, is there any way to do this? 
>
>At the very least it seems like I would have to add the node id from one cluster into the other by hand, since STORE NODE attempts to initialize the node, and I would have to make sure that the node ids got swizzled somehow so that there were no duplicates - it already seems like a mess....
>
>Has anybody had to do this? The nature of our application is that I can't get them all set up in one big cluster ahead of time, because there's a certain amount of dynamic configuration that goes on when new nodes in the system come online.
>
>I suspect this deserves one those slony-was-never-intended-to-do-that answers, but I'd be interested to hear if anybody has had a similar situation.
>  
>
Are the tables involved nicely separate?

If they are, then I'd head down the "STORE NODE" path to make the 
database into one that participates in both replication clusters.

It surely ought to work; STORE NODE starts initializing by creating a 
new namespace, so unless you gave both clusters the same name, the 
namespaces, and hence the Slony-I tables, will be quite separate.  
Separate schemas, separate namespaces for identifying nodes, tables and 
such.  All of it is defined locally inside the _clustername schema.

You would be "breaking new ground," to an extent, but the idea doesn't 
seem stupid.

I could imagine there being the _possibility_ of some additional 
deadlocks as a result of having extra processes hitting the database, 
but in principle that shouldn't be that much worse than adding an extra 
user (one that happens to connect in and do a lot of queries with 
exceeding regularity :-).).

I'd say "try and see."