Andrew, thanks for the response! My responses are inline below: On Thu, 2 Aug 2007, Andrew Hammond wrote:
> On 7/30/07, Jeff Frost <[EMAIL PROTECTED]> wrote: >> >> Hi folks, >> > 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. That's only an issue on subscriber nodes, right? No worries there because I also upgraded it to 8.2.4, so it had to be re-initdb'd, the db created and the schema copied over from the master. >> 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. I would agree, except that running strings against the postgresql binaries that I cpio'd out of the 8.2.4 RPMs yields no lib64. So I'm still not entirely sure what's going on there. They are the community RPMs, so I would think someone would have noticed by now. Also, fgrep -r lib64 through the slony source after the configure yielded no results as well. > > 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. > Neat! I learned a new word (conflate). :-) The reason for this methodology was just speed. Also, we were loading a dump from the production master (this is the QA slony cluster) to bring it up to date before applying the new version changes. There wasn't any need to keep the slave in use, so we tried to do more than one thing at a time. I (erroneously?) thought that starting from a production dump with the _slony schema dropped cascade should work fine for resubscribing, but apparently that's not the case. I'm not sure I understand why that is though. Doesn't a drop cascade of the _slony schema on the master remove every bit of slony tables, functions, etc? > 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 Soon as we get a duplicate environment for this, we'll try that method as well. Thanks again for the ideas! -- Jeff Frost, Owner <[EMAIL PROTECTED]> Frost Consulting, LLC http://www.frostconsultingllc.com/ Phone: 650-780-7908 FAX: 650-649-1954 _______________________________________________ Slony1-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/slony1-general
