Notice in the log snippet that the table data did not get copied from
the provider to the receiver. Also note that sl_table in node 1 includes
the table BUT node 2 does not have an entry for the table.

No errors, warnings, or anything are indicated at any time.

I know the fix that needs to be applied on my side but this is a fairly
significant bug. SET 667 is rather broken now since the nodes have a
different table list.

try {
        create set (id = $ID, origin = 1, comment = 'merge set');
        set add table (set id = $ID, origin = 1, id = $ID, fully
qualified name = '$TAB');

        subscribe set (id = $ID, provider = 1, receiver = 2, forward =
no);
        merge set (id = 667, add id = $ID, origin = 1);
}


2006-04-27 18:34:12 EDT CONFIG storeSet: set_id=960 set_origin=1
set_comment='merge set'
2006-04-27 18:34:12 EDT CONFIG storeSubscribe: sub_set=960
sub_provider=1 sub_forward='f'
2006-04-27 18:34:12 EDT CONFIG storeListen: li_origin=1 li_receiver=2
li_provider=1
2006-04-27 18:34:12 EDT CONFIG storeListen: li_origin=10 li_receiver=2
li_provider=10
2006-04-27 18:34:12 EDT CONFIG storeListen: li_origin=4 li_receiver=2
li_provider=4
2006-04-27 18:34:12 EDT DEBUG1 copy_set 960
2006-04-27 18:34:12 EDT DEBUG1 remoteWorkerThread_1: connected to
provider DB
2006-04-27 18:34:15 EDT DEBUG1 remoteWorkerThread_1: disconnected from
provider DB
2006-04-27 18:34:15 EDT DEBUG1 copy_set 960 done in 2.665 seconds
2006-04-27 18:34:15 EDT CONFIG enableSubscription: sub_set=960
2006-04-27 18:34:15 EDT CONFIG storeListen: li_origin=1 li_receiver=2
li_provider=1
2006-04-27 18:34:15 EDT CONFIG storeListen: li_origin=10 li_receiver=2
li_provider=10
2006-04-27 18:34:15 EDT CONFIG storeListen: li_origin=4 li_receiver=2
li_provider=4
2006-04-27 18:34:15 EDT CONFIG dropSet: set_id=960

--