On Apr 7, 2010, at 10:07 AM, Christopher Browne wrote:

>> Right, I got that, but I'm unclear why some nodes might exist in sl_confirm "long" after they've been removed. I thought (incorrectly, it seems) that one of the fallouts of the DROP NODE command was that all references to that node would be culled.
> 
> It shouldn't get purged instantly...  The event has to propagate to
> other nodes first, otherwise there's a risk of data loss.
> 
> Notably, suppose...
> 
> - Node #4 is being deleted
> 
> - The first node that is told is node #1.
> 
> What happens is that node #1 records a DROP_NODE event for node 4, and
> propagates that to the other nodes in the cluster.
> 
> Node #1 shouldn't purge that event out just yet, otherwise the other
> nodes don't get a chance to know that they, too, need to drop node #4.

Ah, thanks for the clear explanation.