Mon May 30 08:16:25 PDT 2011
- Previous message: [Slony1-bugs] [Bug 217] Changing the primary key of a replicated table leads to trouble
- Next message: [Slony1-bugs] [Bug 217] Changing the primary key of a replicated table leads to trouble
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
http://www.slony.info/bugzilla/show_bug.cgi?id=217 --- Comment #5 from Steve Singer <ssinger at ca.afilias.info> 2011-05-30 08:16:25 PDT --- I have now attached a) A query to detect tables with modified indexes/pkeys b) A function to drop the trigger and re-add it with the proper/new arguments (this takes an exclusive lock on the table) We can modify EXECUTE SCRIPT to check all replicated tables and fix them if they require fixing. Another approach would be to have EXECUTE SCRIPT only fix tables that the current transaction already has an exclusive lock on. If the SQL script submitted to execute script actually changed the primary key/constraint on the table then the transaction would already hold that lock. This condition would mean that EXECUTE SCRIPT still won't obtain any exclusive locks in addition to what the SQL script already has. The downside is that if a table has the wrong trigger arguments prior to EXECUTE SCRIPT being called (ie the primary key was changed outside of EXECUTE SCRIPT and recreate_log_trigger wasn't called) then the error will remain. -- 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.
- Previous message: [Slony1-bugs] [Bug 217] Changing the primary key of a replicated table leads to trouble
- Next message: [Slony1-bugs] [Bug 217] Changing the primary key of a replicated table leads to trouble
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-bugs mailing list