Thu Sep 2 12:16:33 PDT 2010
- Previous message: [Slony1-bugs] [Bug 128] DROP TABLE replicatedTable leaves the cluster in a bad state
- Next message: [Slony1-bugs] [Bug 128] DROP TABLE replicatedTable leaves the cluster in a bad state
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
http://www.slony.info/bugzilla/show_bug.cgi?id=80 Jan Wieck <janwieck at yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|2.0 |devel --- Comment #6 from Jan Wieck <janwieck at yahoo.com> 2010-09-02 12:16:33 PDT --- We have to push this one back to devel. There are several issues with a premature DROP NODE. One is that the function dropNode_int() cleans up after the dropped node. Namely that it deletes every reference to that node from sl_path, sl_listen, sl_confirm, sl_event. This can eventually destroy the FAILOVER_NODE or MOVE_SET event before it was forwarded to everybody else. However, we cannot easily detect what needs to be waited for because it is possible to have a multi-node failure, so some other node will never confirm those events. At this point I don't have a plan how to finally fix this problem. It might require a new event type. -- 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.
- Previous message: [Slony1-bugs] [Bug 128] DROP TABLE replicatedTable leaves the cluster in a bad state
- Next message: [Slony1-bugs] [Bug 128] DROP TABLE replicatedTable leaves the cluster in a bad state
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-bugs mailing list