On Wed, Dec 7, 2011 at 6:53 PM, Tory M Blue tmb...@gmail.com wrote:
Well thought it was maybe just going from 8.4.4 to 9.1.1 so upgraded
to 8.4.9 and tried pg_upgrade again (this is 64bit) and it's failing
-bash-4.0$ /tmp/pg_upgrade --check --old-datadir /data/db
--new-datadir /data1/db --old-bindir /ipix/pgsql/bin --new-bindir
/ipix/pgsql9/bin
Performing Consistency Checks
-
Checking current, bin, and data directories ok
Checking cluster versions ok
Checking database user is a superuser ok
Checking for prepared transactions ok
Checking for reg* system oid user data types ok
Checking for contrib/isn with bigint-passing mismatch ok
Checking for large objects ok
There were problems executing /ipix/pgsql/bin/pg_ctl -w -l
/dev/null -D /data/db stop /dev/null 21
Failure, exiting
I've read some re pg_migrator and issues with contribs, but wondered
if there is something Else I need to know here
I'm not sure that this is on-topic for pgsql-performance, and my reply
here is horribly behind-the-times anyway, but my experience with
pg_upgrade is that it's entirely willing to send all the critically
important information you need to solve the problem to the bit bucket,
as in your example. If you knew WHY it was having trouble running
pg_ctl, you would probably be able to fix it easily, but since
everything's been redirected to /dev/null, you can't. I believe that
this gets considerably better if you run pg_upgrade with the -l
logfile option, and then check the log file.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
