http://www.slony.info/bugzilla/show_bug.cgi?id=217

           Summary: Changing the primary key of a replicated table leads
                    to trouble
           Product: Slony-I
           Version: 2.0
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: low
         Component: trigger SPI
        AssignedTo: slony1-bugs at lists.slony.info
        ReportedBy: ssinger at ca.afilias.info
                CC: slony1-bugs at lists.slony.info
   Estimated Hours: 0.0


This bug has been confirmed in slony 2.1.0 but I would expect it to show up in
2.0.x but not 1.2 or earlier.

Say you have a table test1
create table test1 (
       id1 int4 not null,
       id2 int4 not null,
       id3 int4,
       data text
);
create unique index test1_pkey on test1(id1);

insert into test1(id1,id2,id3,data) values (1,1,1,'test');
insert into test1(id1,id2,id3,data) values (2,2,1,'test2');

and you replicate it specifying the unique index pkey1 on the 'set add table..'
line.

Then you execute the following script through EXECUTE SCRIPT

drop index test1_pkey;
create unique index test1_pkey on test1(id1,id2);
update test1 set id1=1;

Then on the master you do 
update test1 set data='bar' where id2=2

The update matches 1 row on the master.  However when it runs on the slave
slony thinks the primary key is (id1) so it only includes id1 in the where
clause.   This means that two rows will be changed on the slave.

The trigger definition arguments contains 'k' initially, and we have no way of
updating it to 'kk',  nor does the trigger (today) have any way of knowing (at
runtime) that the index has changed.

-- 
Configure bugmail: http://www.slony.info/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.