Cyril SCETBON scetbon at echo.fr
Mon Jul 7 08:15:04 PDT 2008

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


More information about the Slony1-general mailing list