On 2/10/2007 10:20 PM, Christopher Browne wrote:
> I ran into a bug in the handling of the populating of sl_setsync
> recently; thought I'd mention it on the list so that other eyes can
> verify that I'm understanding it, and my intended repair, correctly...
> 
> The problem is thus: When the COPY_SET 'event' completes, it attempts
> blindly to populate a value into sl_setsync to represent the state on
> the provider.
> 
> Unfortunately, it turns out that it is possible for there to already
> be a value, thereby causing the attempted insert to fail, rolling back
> the entire transaction.
> 
> A condition where that can happen is thus:
> 
> - Set up a node, say #5, that is not subscribed to set #4.
> - Do a MOVE SET on set #4; the code for MOVE_SET will populate
>   node #5 with an sl_setsync entry for set #4 even though it is
>   not subscribed to that set.
> - SUBSCRIBE SET (set id = 4, provider = anything, subscriber = 5);
> 
>   It runs into the described condition, "Boom!"
> 
> The temporary corrective measure was to delete the offending
> sl_setsync entry.
> 
> Three corrective approaches come to mind:
> 
> 1.  MOVE SET shouldn't bother setting up a sl_setsync entry if the
>     set isn't subscribed.
> 
> 2.  COPY_SET could do [delete+insert] at the point where the INSERT
>     is now.

The setsync entry is supposed to represent the status or age of the data 
of this set in this node, so these two together should be belt and 
suspender enough. I am currently not sure what happens if you repeatedly 
subscribe and merge a new set, or unsubscribe and resubscribe. There 
might be some loophole and you know that if you have one, sooner or 
later a loop will come through.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== [EMAIL PROTECTED] #
_______________________________________________
Slony1-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/slony1-general

Reply via email to