On Thu, 2 Aug 2007, Andrew Hammond wrote: >>>> 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. > > There is no reason to expect lib64 to appear in the source. If it appears in > your binary, then some part of your build is targeted at a 64bit machine.
But, that's the weird part. It doesn't appear in the binary - neither the slony nor the postgresql ones. *shrug* Maybe it's coming from a shared library somewhere. I'm sure when I find the binary or lib with lib64 in it, I'll find the issue. > > I can't speak for anything involving the RPMs. I don't use them. I build > from source. Since slony is a relatively young piece of code, we continue to > find and patch bugs at a relatively high pace. Not building from scratch may > get you into a sticky situation in production where you need a patched > version and it is not available as a package. > Are you speaking of slony or postgresql RPMs? We're using the postgresql RPMs but slony compiled from source. > I'd expect that a migration process is something you'd want to test in QA > before you did it in production... Sorry, I didn't make it more clear. This was actually the QA cluster we're having issues with so we can get 8.2.4 and slony 1.2.10 well tested in QA for consideration to move it to production. > > 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? > > > It should work fine on pg_dumps that are from the a database that doesn't > subscribe to any sets (an origin-only system). > Excellent! Thanks for validating this point. I was worried I might be making a false assumption. > Hmm, a QA environment doesn't have to be identical to production unless you > intend to do test load / scaling issues. It only needs to be representative. Agreed. More later after we try it again! -- 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
