Bug 174

Making this more concrete...

Set up branch for development...  https://github.com/cbbrowne/slony1-engine/tree/bug174

Proposed...  Add a table that will be replicated via event publishing that captures tuples of the form [excluder, excludee]

That is, node [excluder] will ignore events coming from node [excludee].

(Open question: Will it just be SYNC events that are ignored?  Seems quite likely apropos...)

Add in functions to manage the exclusion table.

https://github.com/cbbrowne/slony1-engine/commit/062e79d42c986fc08e826ef2c0523350ee913abb

4 functions:

- excludenode(excluder, excludee)
- excludenode_int(excluder, excludee)
- unexcludenode(excluder, excludee)
- unexcludenode_int(excluder, excludee)

Exclude functions add in nodes

Unexclude functions remove nodes

Add validation rules:

- You can't add an exclusion if there's a subscription between the nodes

https://github.com/cbbrowne/slony1-engine/commit/5cb7cad6aa22069360be9aa7ad3d5edffd78255d

- You can't set up a subscription if the nodes are involved in exclusion

https://github.com/cbbrowne/slony1-engine/commit/796df78da7e8e639e7df2df642800671ca945b04

(In reply to comment #2)
> Proposed...  Add a table that will be replicated via event publishing that
> captures tuples of the form [excluder, excludee]
> 
> That is, node [excluder] will ignore events coming from node [excludee].
> 
> (Open question: Will it just be SYNC events that are ignored?  Seems quite
> likely apropos...)

How would WAIT FOR (todays manual WAIT FOR - ignoring any automatic one) work if you ignore non sync events?  

Also, just because node 1 is excluding node 4 doesn't mean that node 3 is excluding node 4 (it probably isn't).  How will WAIT FOR change.

Also what are the implications with respect to FAILOVER and MOVE SET or rehshaping a subscription for this change.

Also can you propose some syntax for making a node excluded?

What happens if you no longer want a node to be excluded?  Especially if the events have already been deleted on the excluder.

(In reply to comment #5)
> (In reply to comment #2)
> > Proposed...  Add a table that will be replicated via event publishing that
> > captures tuples of the form [excluder, excludee]
> > 
> > That is, node [excluder] will ignore events coming from node [excludee].
> > 
> > (Open question: Will it just be SYNC events that are ignored?  Seems quite
> > likely apropos...)
> 
> How would WAIT FOR (todays manual WAIT FOR - ignoring any automatic one) work
> if you ignore non sync events?  

> Also, just because node 1 is excluding node 4 doesn't mean that node 3 is
> excluding node 4 (it probably isn't).  How will WAIT FOR change.

If it's only present in the new world (e.g. - where WAIT is implicit), then that's not *totally* important :-).

But sure, it's a good question.

I imagine the result is that events from Node A will get ignored on Node B.

WAIT FOR presently has 2 forms:

a) WAIT FOR a particular node; this only breaks down if you ask to wait for an event from Node A arriving at Node B.  I think we can make such a request error out - it's not sensible to ask for this if there's an "exclusion" present.

b) WAIT FOR ALL.  I expect we'd have these requests ignore exclusions.

Seems sensible?
 
> Also what are the implications with respect to FAILOVER and MOVE SET or
> rehshaping a subscription for this change.

I expect we have to refuse these requests.  It shouldn't be problematic to add tests similar to <https://github.com/cbbrowne/slony1-engine/commit/796df78da7e8e639e7df2df642800671ca945b04> to FAILOVER and MOVE SET.
 
> Also can you propose some syntax for making a node excluded?
> 
> What happens if you no longer want a node to be excluded?  Especially if the
> events have already been deleted on the excluder.

I'd think slonik syntax would look like:

IGNORE NODE (IGNORE ID=2, IGNORE BY=4);
UNIGNORE NODE( ID=2, IGNORE BY=4);

Whether events have been deleted or not seems beside the point; that's a question at the time of SUBSCRIBE SET, MOVE SET, FAILOVER.

(In reply to comment #2)
> Proposed...  Add a table that will be replicated via event publishing that
> captures tuples of the form [excluder, excludee]
> 
> That is, node [excluder] will ignore events coming from node [excludee].
> 
> (Open question: Will it just be SYNC events that are ignored?  Seems quite
> likely apropos...)

This definition is different from the original and changes the semantics fundamentally.

The original idea is to "assume" confirmations in order to avoid keeping events and log data for distant remote nodes.

That does not mean that we ignore events at all. It means that we don't care when a node 2 hops away catches up to them.