Ah, you know, I wasn't even thinking of just having separate slony
namespaces! My current implementation is using the same namespace
everywhere, but these new requirements are bumping it up a level of
complexity, and that naming assumption was still hanging around in my
rapidly-aging brain....

Thanks for the suggestion. I'll give it a try.

- DAP 

>-----Original Message-----
>From: Christopher Browne [mailto:cbbrowne at ca.afilias.info] 
>Sent: Friday, January 14, 2005 4:07 PM
>To: David Parker
>Cc: slony1-general at gborg.postgresql.org
>Subject: Re: [Slony1-general] cluster "merge"
>
>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."
>