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