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

--- Comment #4 from Steve Singer <ssinger at ca.afilias.info> 2010-07-30 08:57:00 PDT ---

The issues described in this bug can also show up in a case like this

1==>3===>4
||  \\   
2     5   



FAILOVER 1===>4

Slonik executes failedNode2 on node 3.  This means that node 3 has a FAILOVER
event in its sl_event with an origin of node 1.  That failover event needs to
propogate to node 4.

The issue is that the FAILOVER command 'looks' like it is coming from node 1
but it is sitting on the queue at node 3.

The sl_listen configuration at node 4  looks as follows (after failedNode() has
been executed on node 4, the backup node)
select * FROM _disorder_replica.sl_listen where li_receiver=4;
 li_origin | li_provider | li_receiver 
-----------+-------------+-------------
         2 |           2 |           4
         3 |           3 |           4
         5 |           5 |           4
         2 |           5 |           4
         3 |           5 |           4
         3 |           2 |           4
         5 |           2 |           4
         2 |           3 |           4
         5 |           3 |           4
         1 |           2 |           4

 select * FROM _disorder_replica.sl_subscribe ;
 sub_set | sub_provider | sub_receiver | sub_forward | sub_active 
---------+--------------+--------------+-------------+------------
       1 |            2 |            4 | t           | t
       1 |            4 |            2 | t           | t
       1 |            4 |            3 | t           | t
       1 |            4 |            5 | t           | t
(4 rows)


This is because failedNode() has already modified sl_subscribe so node 2 and
node 3 are receiving data from node 4.

Because node 4 has a sl_subscribe row saying it gets the set from node 2 (and
set 1 is still set to have node 1 as an origin) node 4 stops listening for node
1 origin events from node3.

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