http://www.slony.info/bugzilla/show_bug.cgi?id=321

--- Comment #6 from Steve Singer <ssinger at ca.afilias.info> 2013-10-18 12:04:16 PDT ---
What I think is going on is this:

The Failover.js test has the following:

   this.moveSet(1,2,1);
    //stop slon 4
    this.coordinator.log('starting bug 318 test');
    this.slonArray[3].stop();
    this.coordinator.join(this.slonArray[3]);
    load2 = this.generateLoad();
    this.coordinator.log('stopping load');
    java.lang.Thread.sleep(3*30*1000);
    load2.stop();
    this.slonArray[3] = this.coordinator.createSlonLauncher('db4');
                this.slonArray[3].run();    
    this.failNode(1,3,true);

We get setup for the test by configuring node 1 as the master,  then we stop
the slon on 4 and generate a backlog.

When we startup slon 4 again, we see the following in the slon 4 log AFTER
slonik
has issued the FAILOVER command (but before it completes)

remoteListenThread_5: queue event 1,5000000005 SYNC
remoteListenThread_5: queue event 1,5000000006 ACCEPT_SET
 remoteListenThread_5: queue event 1,5000000007 SYNC
.
.
.



Basically  slon 4 has not yet seen the ACCEPT_SET from 1, so it has a listen
network that is out of date.    The remote listener queues up the SYNC events
of 1 from provider 5.   When node 1 becomes the origin these events are still
in the queue.  The remoteWorkerThread starts to then process 1,5000000007 where
the event provider is 5 but that isn't in the provider list.

-- 
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.