On 7/30/07, Jeff Frost <[EMAIL PROTECTED]> wrote: > > Hi folks, > > In an effort to upgrade a cluster from slony1-1.2.6 and postgresql-8.1.8, > I > dumped the DB, upgraded to postgresql-8.2.4, comiled and installed > slony1-1.2.10 and then tried to restore the DB on the master. The restore > crashed the backend every time when trying to restore our slony_test > table. > So I opted to go a different route and installed 8.1.9, moved the old data > directory in, dropped the slony schema cascade and dumped the db. Then I > restored that into 8.2.4 successfully. After upgrading the slave to 8.2.4and > 1.2.10, I tried to subscribe the slave,
I bet you took the short-cut of not dropping the database and reloading a fresh schema. Simply dropping the _slony schema with cascade is _not_ sufficient on subscriber nodes. but the slonik command errored out and > left the following in the postgresql log: > > Jul 29 15:48:49 testdb1 postgres[1173]: [1-1] ERROR: could not access > file > "$libdir/xxid": No such file or directory > Jul 29 15:48:49 testdb1 postgres[1173]: [1-2] STATEMENT: load > '$libdir/xxid'; > > This is what slonik complained about: > > <stdin>:17: PGRES_FATAL_ERROR load '$libdir/xxid'; - ERROR: incompatible > library "/usr/lib64/pgsql/xxid.so": missing magic block > > Except, I don't know why it's looking in /usr/lib64/pgsql because this is > a 32 > bit CentOS 4.3 machine. I double checked that the i686 versions of > postgres > are installed, slony was compiled from source against /usr/bin/pg_config > which > correctly outputs that libdir is /usr/lib/pgsql: > PKGLIBDIR = /usr/lib/pgsql > > What am I missing? Is there a special procedure for using > Postgresql-8.2.4? Sounds like your build is broken. It yielded the same results with slony 1.2.8 and 1.2.9. But, 1.2.10 is > working fine with postgresql-8.1.9 which we reverted to. I'm a little confused as to why you would conflate a database upgrade with a replication upgrade. The usual process (or at least the one I've regularly used) is as follows. 1) Upgrade cluster to latest slony (assuming you plan to upgrade slony) 2) add a new node, running on the new version of PostgreSQL 3) make sure you're happy with the new node 4) promote new replica to origin For each old node, 1) drop old node from replication 2) re-initdb with newest postgresql binary 3) subscribe new node to cluster Andrew
_______________________________________________ Slony1-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/slony1-general
