Re: pg_upgrade failure "contrib" issue?

On Wed, Dec 7, 2011 at 6:53 PM, Tory M Blue <tmblue(at)gmail(dot)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