Summary: | Create a CANCEL SUBSCRIPTION command | ||
---|---|---|---|
Product: | Slony-I | Reporter: | Christopher Browne <cbbrowne> |
Component: | slon | Assignee: | Slony Bugs List <slony1-bugs> |
Status: | RESOLVED WONTFIX | ||
Severity: | enhancement | CC: | slony1-bugs |
Priority: | medium | ||
Version: | devel | ||
Hardware: | All | ||
OS: | All | ||
URL: | http://lists.slony.info/pipermail/slony1-hackers/2007-May/000011.html | ||
Bug Depends on: | 111 | ||
Bug Blocks: |
Description
Christopher Browne
2007-11-13 13:07:02 UTC
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 *** Bug 20 has been marked as a duplicate of this bug. *** |