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

Jan Wieck <janwieck at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|slony1-bugs at lists.slony.inf |janwieck at yahoo.com
                   |o                           |

--- Comment #3 from Jan Wieck <janwieck at yahoo.com> 2010-08-24 07:23:57 PDT ---
The issue is actually the async processing of events coming from different
nodes.

The FAILOVER_NODE is faked by slonik to be coming from the failed node. This
guarantees that every subscriber will drain out all outstanding SYNC events
from the failed node before starting to consume changes from the next origin
(either backup node or temporary origin). 

The next origin will issue ACCEPT_SET. The purpose of the ACCEPT_SET event,
which is also seen in MOVE_SET, is that a subscriber suspends processing events
from the accepting node, until it has seen the corresponding FAILOVER_SET or
MOVE_SET, so that it doesn't throw away data from the accepting node. The
accepting node can modify the tables and create sl_log data long before
everybody else is caught up.

What we want to do is to reproduce the ACCEPT_SET logic in slon for DROP_NODE
and suspend processing events from the DROP_NODE origin until there are no more
sets from that origin in slon's runtime config.

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