[Pkg-postgresql-public] Slony upgrade path

Cédric Villemain cedric.villemain at dalibo.com
Mon Nov 30 09:36:05 UTC 2009

Le vendredi 27 novembre 2009 22:01:58, Peter Eisentraut a écrit :
> I want to discuss some ideas on how to handle the Slony major version
> upgrade.
> This is the situation:  In lenny/stable we have Slony 1.2.15 built for
> PostgreSQL 8.3, with package names being
> postgresql-8.3-slony1 1.2.15-1
> slony1-bin 1.2.15-1
> slony1-doc 1.2.15-1
> The latest upstream is Slony 2.0.2 (or maybe 2.0.3 soon).  Now 2.0 is
> not compatible with 1.2, meaning that to upgrade you need to drop the
> replication and reinstall it.  So this is perhaps not unlike the
> PostgreSQL major version upgrades in spirit.  No word yet on a 2.1, but
> I think it's safe to assume that it would be compatible with 2.0.
> (Version numbering side note: The proper name of the product is
> "Slony-I" (slony one), and it itself comes in versions 1.x and 2.x.
> There is also something else called Slony 2, although now defunct, I
> think.  This will result in some silly version numbers below.)

it is defunct.

> The question now is what to package for squeeze and how, and how to not
> break anything during the upgrade.
> Obviously, I'm not going to try any automated custom in-place upgrades
> of replication clusters. ;-)  The approach is going to be more like
> packaging both side-by-side.
> I can see the following solution: Full scale parallel packaging for one
> release, with versioned package names and dummy packages to pull in the
> preferred one.  So in squeeze we'd have something like
> source: slony1
> postgresql-8.4-slony1-1 1.2.17
> slony1-1-bin 1.2.17
> slony1-1-doc 1.2.17
> source: slony1-2
> postgresql-8.4-slony1-2 2.0.3
> slony1-2-bin 2.0.3
> slony1-2-doc 2.0.3
> also built by slony1:
> postgresql-8.4-slony1 1.2.17 depends: postgresql-8.4-slony1-1
> slony1-bin 1.2.17 depends: slony1-1-bin
> slony1-doc 1.2.17 depends: slony1-1-doc
> And put in a note that people need to upgrade to slony 2.x during the
> lifetime of squeeze, and then in squeeze+1 change the dependencies of
> the dummy package to slony1-2*.
> Also, you will not be able to install postgresql-8.4-slony1-1 and
> postgresql-8.4-slony1-2 at the same time, and neither slony1-1-bin and
> slony1-2-bin.  (Not sure about the -doc packages.)
> So a complete upgrade path from lenny PG 8.3 + Slony 1.2 might be:
> 1. Upgrade Debian to squeeze; installs postgresql-8.4 and
> postgresql-8.4-slony1-1 etc.
> 2. Migrate PostgreSQL from 8.3 to 8.4 (perhaps using slony).
> 3. Upgrade Slony setup from 1.2 to 2.0 during squeeze lifetime.
> Comments?  Other ideas?

It is a good process.
People have to well understand that they have to *drop/reinit* replication. 
Which is a very bad time for DBA.

perhaps a tool to recover a clean script for slonik. So I'll just add a step :

2.5. dump slonik config from current install (just the script necessary to init 
replication) and what to do with it. It help to have a more confortable 
At this time it will be possible to tell again that a native primary key by 
table is more than welcome instead of the ugly one provided internaly by 

Even if possible, I am against an automatic upgrade too.

> _______________________________________________
> Pkg-postgresql-public mailing list
> Pkg-postgresql-public at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/pkg-postgresql-public

Cédric Villemain
Administrateur de Base de Données
Cel: +33 (0)6 74 15 56 53
http://dalibo.com - http://dalibo.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-postgresql-public/attachments/20091130/1c0a3769/attachment.pgp>

More information about the Pkg-postgresql-public mailing list