Bug 212

Summary: moveSet leaves cluster with no origin
Product: Slony-I Reporter: Steve Singer <ssinger>
Component: stored proceduresAssignee: Slony Bugs List <slony1-bugs>
Status: NEW ---    
Severity: enhancement CC: slony1-bugs
Priority: low    
Version: devel   
Hardware: PC   
OS: Linux   

Description Steve Singer 2011-05-12 14:07:50 UTC
This came up while testing 2.1.0.b1 

I was testing the perl tools but this bug isn't specific to the perl tools (it is possible that someone might write the exact same slonik scripts by hand)

I had node 1,2,3

I made node 2 the origin of my set (set 1) and I dropped node 1.
I then recreated node 1, subscribed it to set 1 and did a move set from 2=>1.

This is what I see in sl_event.
         2 | 5000000089 | 2011-05-12 16:29:48.373039-04 | 7950418:7950418:        | MOVE_SET    | 1        | 2                       | 1                                              

         2 | 5000000093 | 2011-05-12 16:30:39.686974-04 | 7950595:7950595:        | ACCEPT_SET  | 1        | 1                       | 2   

That is a MOVE_SET for set 1 from 2=>1  but an ACCEPT_SET for 1=>2.

sl_set on node 2 shows:

select * FROM _test.sl_set;
 set_id | set_origin | set_locked |  set_comment   
--------+------------+------------+----------------
      1 |          2 |    7951141 | Set 1 for test
(1 row)

select con_received, max(con_seqno) FROM _test.sl_confirm where con_origin=2 group by con_received;
 con_received |    max     
--------------+------------
            3 | 5000000151
            1 | 5000000143
(2 rows)


I don't yet know how easy it is to reproduce this situation.
Comment 1 Steve Singer 2011-07-08 11:41:56 UTC
It is possible that commit 40560a4515b3febfdd368cca89ad4c3c73456ae2 fixed the underlying cause but since this issue wasn't easily reproducible it is hard to say.