On Wed, Dec 7, 2011 at 6:53 PM, Tory M Blue <tmblue@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" 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