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

           Summary: replicate_partition stored procedure doesn't start
                    replicating changes to the new table
           Product: Slony-I
           Version: 1.2
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: low
         Component: stored procedures
        AssignedTo: slony1-bugs at lists.slony.info
        ReportedBy: ssinger at ca.afilias.info
                CC: slony1-bugs at lists.slony.info
   Estimated Hours: 0.0


Create a set 1 and add table a to set 1 and subscribe at least one receiver to
the set.

Then create an inherited table b (that inherits from a).

The http://www.slony.info/documentation/partitioning.html leads one to belive
that you can do 

 SELECT _test.replicate_partition(2,'public','b','b_pkey','none');

and that seems to work (ie it gives no error) but it leaves slony in a not so
good state.  

If you run this on the origin you get
-A row in sl_table with tab_altered=f.  B on the origin does NOT have hte log
trigger installed
-This command does nto change sl_table on subscribers.

The issues I see are

-add_empty_table_to_replication calls setAddTable_int not setAddTable.
setAddTable_int does NOT create a SET_ADD_TABLE event so the subscriber is
never told to change its state(sl_table)
-After calling setAddTable the add_empty_table_to_replication function calls
alterTableRestore() on the table which deletes the log trigger.

Was there a reason for this?  Further to note, setAddTable will check to make
sure the set is not subscribed (which it probably is, see the motiviation at
the top of the documentation page linked above)

I think we want to replace teh alterTableRestore() call with a SET_ADD_TABLE
create event

-- 
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.