Mon Jul 7 08:15:04 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 ]
Jacques Caron wrote: > 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), OK > 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. it seems that it was not working without doing this action (adding the v) even if our primary key is the first column. > Of course you shouldn't delete a column that is part of the primary > key (or change the primary key or anything like that). that's not the case. > > 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. that's why I've initiated this thread. Cause We get a lot of DML orders and everything was locked during the execute script. We cannot use the EXECUTE SCRIPT as long as it works that way. > > In short, EXECUTE SCRIPT will attempt very strongly not to let you > shoot yourself in the foot, yes > 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)! :-) We'll take care and try to know what we do and to think that the things that we do are good :-) > > Jacques. > > _______________________________________________ > Slony1-general mailing list > Slony1-general at lists.slony.info > http://lists.slony.info/mailman/listinfo/slony1-general -- Cyril SCETBON
- 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