On Wed, Dec 7, 2011 at 6:53 PM, Tory M Blue <tmblue@xxxxxxxxx> 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" 2>&1 > 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@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
