Ben Chobot <bench at silentmedia.com> writes:
> On Apr 7, 2010, at 12:56 AM, Stéphane A. Schildknecht wrote:
>
>> Hi,
>> 
>> In fact, Slony did not get confused. sl_status is a view composed with
>> information from sl_event and sl_confirm.
>> Until every event referencing the deleted nodes disappear from these tables,
>> you will see these nodes in sl_status.
>> 
>> The fact that these nodes are not shown in sl_nodes is a good way to know they
>> don't exist in the cluster anymore.
>
> 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.

Ergo, it's not instantaneously culled from events/confirmations.
-- 
(reverse (concatenate 'string "ofni.sailifa.ac" "@" "enworbbc"))
Christopher Browne
"Bother,"  said Pooh,  "Eeyore, ready  two photon  torpedoes  and lock
phasers on the Heffalump, Piglet, meet me in transporter room three"