I'd encourage you to explore ways to constrain your requirements in some way.

Regardless of your ability to play tricks on slony in this scenario, it feels like you are setting
yourself up for a testing and operational nightmare.

Maybe a better way to visualize this is to forget replication for a minute. Imagine that I have a
single machine that has the 1.32, 1.34, and 1.35 applications installed on it such that I can stop
one application and start another one at any time. Imagine that I have a magic tool that will take
the data for a 1.34 schema and copy it to a 1.35 schema.

If I need to be prepared to stop version X, run the magic tool to convert the data, and start
version Y at any point in time, what do I need to do? I need to test for full forward and backward
compatibility (i.e., I need to run a 1.32 application against a database that was written by a 1.35
application (with suitable magic changes) - and vice versa). I need to constrain my schema changes
in such a way that an old application can run without the new column entirely, and a newer
application can do its work rationally without counting on having that column populated.

Are you using slony strictly for one-way replication (e.g., the current master node will always be
the master, with data flowing out to the slaves) or do you need to be prepared to have any slave
become a master?

If you need to be able to have any node be a master, then you have the full weight of the arbitrary
testing scenario on you. If node 1 is the only one that can be a master, and you are able to at
least set things up such that node 1 is always the first (or last) upgraded, then you can simplify
your testing quite a bit.

If your applications have subtle bugs due to forward/backward compatability issues, or you aren't
able to failover nodes when you need to, having a more contrained but more easily verified system
will look cheap in comparison.

I don't know how hard your constraints are or where you might have some flexibility. My concern is
that you may have both feet in a bucket and one hand tied behind your back, and it's not clear that
our advice (from the slony community) telling you how you can hop sideways while spinning a bit in
the air will really help you solve your true business problem.

Michael

On 5/31/10 6:25 AM, 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.
> 
> Can slony be used if the slave schemas are slightly different from the
> master one?
> 
> 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
> - add/drop a table
> 
> 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?
> 
> 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
> 
>