Mon Jul 7 06:31:58 PDT 2008
- Previous message: [Slony1-general] how to prevent EXECUTE SCRIPT from locking alltables
- Next message: [Slony1-general] how to prevent EXECUTE SCRIPT from locking alltables
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
At 14:31 07/07/2008, Cyril SCETBON wrote: >What the difference between adding and removing a column ? (in the >case, there's no constraint) Adding a column without using EXECUTE SCRIPT works because Slony logs the column names and builds statements with those names. For instance, if you have a table with two columns a and b, it will use statements of the form INSERT INTO table (a,b) VALUES(1,2) on the slaves. So if you add the column on the destination(s) first, those statements will work, and the new column will just have its default value (that's one of the reasons you don't want to have a constraint on that new column: the constraint is likely to break). If you delete a column, then you should do it on the master first, and the destinations afterwards (actually, only once any inserts/updates on the table generated prior to the column deletion on the master have been processed on all nodes), otherwise you'll get statements referencing the columns that don't exist anymore. There should be no constraint on the column to delete either (otherwise you may end up with Slony inserting default values on the slave that don't match the constraint). You may also have to modify the trigger argument (removing one "v" in the right place), though that's not necessary if your primary key columns are the first ones. Of course you shouldn't delete a column that is part of the primary key (or change the primary key or anything like that). In reality, there are a lot of things you can actually do without EXECUTE SCRIPT if there is no activity on the table you're modifying (and possibly any other tables that reference them etc.). The only problem being that you actually have to *think* (carefully) about the consequences of any changes, so as pointed out by Andrew, EXECUTE SCRIPT has to take such extensive locks because it can't know if the DDL you're submitting is "safe" to execute with minimal locking or not. In short, EXECUTE SCRIPT will attempt very strongly not to let you shoot yourself in the foot, while doing DDL changes directly on the different nodes is an ICBM targeted at your foot if you don't know what you are doing (and even if you think you do)! :-) Jacques.
- Previous message: [Slony1-general] how to prevent EXECUTE SCRIPT from locking alltables
- Next message: [Slony1-general] how to prevent EXECUTE SCRIPT from locking alltables
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-general mailing list