On Mar 22, 2010, at 7:10 PM, Steve Singer wrote:

> Ben Chobot wrote:
>> Hey guys,
>> I have a database I'm currently replicating with slony. Most tables are in the same set. I've recently been given the requirement that a few of my tables need to be replicated to an additional slave. I'm new to Slony, but I believe this means I'll need to create a new set, subscribe the current slave and the new, lesser slave to that new set, and then move those tables into the new set. Is that correct?
>> If so, then I have a concern with the minimum amount of tables I actually need to put into my new set. There is a very specific list of tables I want to replicate to my new slave. However, the documentation leads me to believe that I don't want foreign keys to cross set boundaries, and that means I would need to put more tables into my new set than I wish. Can somebody explain why foreign keys crossing sets is bad? I *think* it might be because slony might not apply updates from multiple sets in a single transaction - but if that was the case, then it seems that having foreign keys span set boundaries wouldn't merely be undesirable, but rather unworkable. So.... I must have something wrong?
> 
> So you currently have sets 1 replicating to nodes A and B.  You then create your set 2 that replications from A to B but also to node C.
> 
> There is nothing stopping your from issuing a move set command to move the set 2 origin to be node C.  Now node B is receiving updates for set 1 from node A and updates for set 2 from node B.   Node A might even see  set of changes from node C before those changes make it to node B. Someone might then insert a row on node A that references the foreign key.  That chance can also be sent from node A to node B before node B receives the original chance from node C.

Right, if we make the origins on different nodes, that's clearly asking for problems. But if we keep all set origins to be on the same node? I understand slony doesn't enforce that, but assuming I don't try so hard to shoot my foot, might I referential integrity problems? 

> When does something cross the line from being unmanageable to unworkable? Rather than debating that point you are probably better off spending time trying to find a way to do what you want without having foreign keys that cross set boundaries.

Any suggestions on a better way to go about it?