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.
3. COPY_SET could check to see if there's a value in sl_setsync
during the "prepare set" portion (e.g. - in the part at the
beginning where it verifies that all tables/sequences are
present)
I suspect I should do all three, as a "belt + suspenders" approach
:-). With priority on 2 + 3; the code in MOVE SET is complex enough
that it seems to me that introducing a fix there might make the code
more opaque, which doesn't seem to be a good change ;-).
--
(reverse (concatenate 'string "ofni.sailifa.ac" "@" "enworbbc"))
<http://dba2.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)
_______________________________________________
Slony1-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/slony1-general
