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


Christopher Browne <cbbrowne at ca.afilias.info> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED




--- Comment #1 from Christopher Browne <cbbrowne at ca.afilias.info>  2008-02-27 09:25:24 ---
Describing this in greater detail...  Please ignore the earlier discussion...

Consider the slonik statement:
cancel subscription (id=1, origin=1, receiver=3);

Where the subscription arrangement is to be...

  1 --> 2 --> 3 --> 4

Firstly, there are failure cases where this SHOULD fail:
- If node #3 is subscribed, according to node 3, and is feeding #4, according
to node #3, then the request should FAIL!  Nothing's broken!  Moreover, we
can't drop the subscription without causing other breakage (e.g. - leaving a
downstream node, that also appears to be working, orphaned).
- If node #3 subscription is complete, according to node #3, then FAIL!  Again,
nothing's broken with node #3.

Some Impossibilities

- Requests to subscribe to #3 will fail until node #2 has been subscribed.
- Therefore, we don't need to worry about cases where upstream subscriptions
aren't ready.  We can focus on node #3 alone.
- There is never a reason to need to look at node #2; only #1 and #3 need to be
considered.

There are now really only the following cases:

1.  Subscribe set hasn't been processed against node #3. 

We inject code into SUBSCRIBE SET that looks for a CANCEL SUBSCRIPTION later in
the event stream, and if it is found, it replaces SUBSCRIBE_SET with
CANCEL_SUBSCRIPTION, in sl_event, does a COMMIT on that, and then "fails."  The
slon will reattempt the event, find a CANCEL_SUBSCRIPTION.

2.  Subscribe set has been processed, but not the "enable subscription" event.

We inject code as above into ENABLE SUBSCRIPTION.

3.  Enable subscription is in progress.

There may be a race condition here, where the subscription may complete before
we get done; if that is the case, then the subscription will have succeeded,
and we're too late to cancel it.

Absent of that, the slonik request should follow CANCEL SUBSCRIPTION (id,
origin, receiver) with RESTART NODE (id=receiver).  That will cause the slon
for the subscriber node to shutdown and restart itself, and, assuming the
subscription was not complete, this will lead to the slon retrying the
ENABLE_SUBSCRIPTION event,which will cause it to perform the logic of #2, above


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