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

           Summary: DROP TABLE replicatedTable leaves the cluster in a bad
                    state
           Product: Slony-I
           Version: 2.0
          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


Add a table to replication (say sometable)

Then do 

DROP TABLE sometable. (even via execute script)

Then try:
1) MOVE SET:  fails with: 
    <stdin>:13: PGRES_FATAL_ERROR select "_disorder_replica".moveSet(3, 3);  -
ERROR:  Slony-I: alterTableConfigureTriggers(): Table with id 8 not found


2) SET DROP TABLE(id=8,origin=1) gives
 <stdin>:12: PGRES_FATAL_ERROR select "_disorder_replica".setDropTable(8);  -
ERROR:  Slony-I: alterTableDropTriggers(): Table with id 8 not found

Forgetting to remove a table from replication before dropping it is a pretty
common mistake.  There needs to be a clean (and obvious) way to recover from
this short of manually changing sl_table.

I propose that the setDropTable be modified so that if the
alterTableDropTriggers() function fails on a table we are about to drop then we
proceed with dropping the table anyway.   Having moveSet() fail when the table
deosn't exist is still resonable.

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