Lorenzo Bolzani wrote:
> 
> Hi all,
> I'm evaluating for my current project.
> 
> I suspect this question has been answered several times but I checked 
> the docs and google and I didn't found a clear answer.

That is because the answer is "it depends"

> 
> Can slony be used if the slave schemas are slightly different from the 
> master one?
> 

Yes, depending on what 'slightly means'

> We have a 1 master and 2 slave installations of a system automation 
> application. The application can be upgraded independently on the three 
> nodes.
> 
> So this could be an actual scenario:
> 
> master:  version 1.34
> slave1:  version  1.35
> slave2:  version  1.32
> 
> Any version update could imply some schema changes, for example:
> 
> - add/drop/modify a column

You can add columns on the replica safely (if your using version 1.2.x 
remember to use EXECUTE SCRIPT  with the ONLY ON option).

If you DROP a column from the replica on a replicated table you will 
have a problem when slony tries to replicate data into the table but you 
can drop columns from the origin before they are dropped from the 
replica (as long as they are NOT NULL columns).




> - add/drop a table
>

You can add a table to the origin and not replicate it, similarly you 
can add a table to the replica and it doesn't need to exist on the 
origin.   If you want to drop a replicated table you will need to first 
make it a non-replicated table by removing it from your replication set 
(then you can do whatever you want, assuming you have no foreign key 
issues, since it isn't replicated anymore)



> The schema changes must NOT be replicated because any version of the 
> running application expects different schemas (of course small changes 
> can be replicated without problems).
> 
> What I'd like slony to do is to handle missing columns (with defaults if 
> not null), extra columns (ignoring), and for big changes transform data 
> through a custom script.
> 
> Can this be achieved?

I think so, if your careful about the ordering you apply things etc...

> 
> It's acceptable, for the most complex cases, to use temporary tables to 
> save changes to be applied later on the actual ones.
> 
> 
> Thanks for any pointer
> 
> 
> Bye
> 
> Lorenzo
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at lists.slony.info
> http://lists.slony.info/mailman/listinfo/slony1-general


-- 
Steve Singer
Afilias Canada
Data Services Developer
416-673-1142