bugzilla-daemon at main.slony.info bugzilla-daemon at main.slony.info
Tue Jul 9 20:08:02 PDT 2013
http://www.slony.info/bugzilla/show_bug.cgi?id=299

           Summary: moveset can cause a subscriber to pull data it has
                    already seen
           Product: Slony-I
           Version: devel
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: low
         Component: slon
        AssignedTo: slony1-bugs at lists.slony.info
        ReportedBy: ssinger at ca.afilias.info
                CC: slony1-bugs at lists.slony.info
   Estimated Hours: 0.0


This bug has been observed with a recent 2.2.0 development branch.

following a MOVE SET a subscriber that is neither the old or new origin can try
to replicate data from it's provider that it has already seen.


subscribe set(id=1, provider=1, receiver=3,forward=yes);
subscribe set(id=1,provider=1,receiver=2,forward=yes);
subscribe set(id=1,provider=3,receiver=4,forward=yes);

-- add a row on node=1, let it replicate to node=3 (but maybe not node=2).
Then

lock set(id=1,origin=1);
move set(id=1,old origin=1,new origin=2);

This doesn't happen everytime but I have reproduced it a number of times when
starting/stopping the various slons at different points.

This output is from the slon for node=3


2013-07-09 22:41:39 EDT CONFIG moveSet: set_id=1 old_origin=1 new_origin=2
2013-07-09 22:41:39 EDT CONFIG remoteWorkerThread_2: update provider
configuration
2013-07-09 22:41:39 EDT CONFIG remoteWorkerThread_2: added active set 1 to
provider 1
2013-07-09 22:41:39 EDT CONFIG storeListen: li_origin=1 li_receiver=3
li_provider=1
2013-07-09 22:41:39 EDT CONFIG storeListen: li_origin=4 li_receiver=3
li_provider=4
2013-07-09 22:41:39 EDT CONFIG storeListen: li_origin=1 li_receiver=3
li_provider=2
2013-07-09 22:41:39 EDT CONFIG storeListen: li_origin=4 li_receiver=3
li_provider=1
2013-07-09 22:41:39 EDT CONFIG storeListen: li_origin=1 li_receiver=3
li_provider=4
2013-07-09 22:41:39 EDT CONFIG remoteWorkerThread_2: update provider
configuration
2013-07-09 22:41:39 EDT CONFIG remoteWorkerThread_2: added active set 1 to
provider 1
2013-07-09 22:41:39 EDT CONFIG remoteWorkerThread_4: update provider
configuration
2013-07-09 22:41:39 EDT CONFIG remoteWorkerThread_4: helper thread for provider
4 terminated
2013-07-09 22:41:39 EDT CONFIG remoteWorkerThread_4: disconnecting from data
provider 4
2013-07-09 22:41:39 EDT CONFIG storeListen: li_origin=4 li_receiver=3
li_provider=2
2013-07-09 22:41:39 EDT CONFIG storeListen: li_origin=2 li_receiver=3
li_provider=1
2013-07-09 22:41:39 EDT CONFIG remoteWorkerThread_2: update provider
configuration
2013-07-09 22:41:39 EDT CONFIG remoteWorkerThread_2: added active set 1 to
provider 1
2013-07-09 22:41:39 EDT CONFIG remoteWorkerThread_4: update provider
configuration
2013-07-09 22:41:39 EDT INFO   remoteWorkerThread_1: syncing set 1 with 1
table(s) from provider 1
2013-07-09 22:41:39 EDT ERROR  remoteWorkerThread_1_1: error at end of COPY IN:
ERROR:  duplicate key value violates unique constraint "stest_pkey"


Notice that there is no
remoteWorkerThread_1 with update provider configuration

I think that means that adjust_provider_info has not yet run for the node 1
providers, remoteWorkerThread_1 still thinks node 1 is the origin for set 1,
but sl_setsync has been updated to show otherwise.

-- 
Configure bugmail: http://www.slony.info/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.


More information about the Slony1-bugs mailing list