Several tests I was running lately suffered from the lack of being able 
to consistently wait for the SUBSCRIBE SET event. It is essential to be 
able to wait for this one since it can lead to serious cluster confution 
if for example a MERGE SET is issued before the subscriber has picked up 
the new set.

This lead to a new slonik command

     SYNC (id = <nodeid>);

The SYNC command simply creates a classic SYNC event, so there is no 
additional support needed in either slon or the backend side functions. 
What this allows however is for slonik to create a simple event and wait 
for it to be confirmed. The proper sequence to wait for a subscription 
to complete would be:

     subscribe set (id = 10, provider = 1, receiver = 2);
     wait for event (origin = 2, confirmed = 1);
     sync (id = 1);
     wait for event (origin = 1, confirmed = 2);

The subscribe set event will be generated on the new subscriber, node 2. 
When this is confirmed by node 1 (the origin), it will have generated 
the ENABLE_SUBSCRIPTION event in the same transaction. The enable event 
is what actually causes the new subscriber to execute the copy_set(), so 
the subscription itself will be done when that event is confirmed by 
node 2. The sync command therefore will generate a SYNC event that is 
guaranteed to have a higher ev_seqno than the ENABLE_SUBSCRIPTION event. 
The following wait for event will actually finish after node 2 not only 
has finished the copy_set() but also at least the initial SYNC after that.

The new functionality is committed into REL_1_1_STABLE, REL_1_2_STABLE 
and HEAD.

Who is up for adding the required documentation including hints in the 
sections for SUBSCRIBE SET, MERGE and the like?


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #