Hi Chrisopher,

Recently I've been thinking about the reason why initial data  
transfers cannot be programmed to occur one structure at a time. As  
you know, syncing up 500 structures individually and merging into a  
master set as you go instead of in a single SET transfer (single  
large transaction) is far better for the master node.

The reason it cannot be done currently is that a single SET cannot be  
transferred into components without causing issues.


What about adding a command that is the opposite of a MERGE?

When subscribing to a set, slony could do the following:

The big catch is the set number has to change.

Externally we issue something like:

SUBSCRIBE SET (ID = 10, PROVIDER = 1, RECEIVER = 2, TRANSFERRED SET =  
11);


Slony creates an empty set 11 which is immediately subscribed to  
receiver 2.

Then it does the following:

foreach $table (@tables_in_set_10) {

        # Split set copies the state of ID 10 to a newly built set 999.
        # It moves the table from being a part of 10 to 999
        SPLIT SET (ID = 10, MOVE TABLE = $table, NEW SET = 999);
        WAIT FOR EVENT (ORIGIN = 1, CONFIRMED = 2);
        SYNC (ID = 1);

        SUBSCRIBE SET (ID = 999, PROVIDER = 1, RECEIVER = 2);
        WAIT FOR EVENT (ORIGIN = 2, CONFIRMED = 1);
        SYNC (ID = 1);

        MERGE SET (ID = 11, ADD ID = 999, ORIGIN = 1);
        WAIT FOR EVENT (ORIGIN = 2, CONFIRMED = 1);
        SYNC (ID = 1);
}

# All tables are now in set 11. Heck, could even rename 11 to 10
REMOVE SET (ID = 10);



Sure, it's a little fragile but would be a very welcome addition. A  
built in SPLIT SET function would allow us to write the wrapper on  
our own.
_______________________________________________
Slony1-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/slony1-general

Reply via email to