于2012年9月14日 22:26:16,Bruce Momjian写到:
> On Fri, Sep 14, 2012 at 01:43:30PM +0800, Rural Hunter wrote:
>> I am trying to test the upgrade from my 9.1.3 db to 9.2 on ubuntu
>> 10.10 server. I got error below when run the pg_upgrade command.
>> What can I do for this?
>>
>> $ /opt/PostgreSQL/9.2/bin/pg_upgrade -b /opt/PostgreSQL/9.1/bin -B
>> /opt/PostgreSQL/9.2/bin -d /raid/pgsql -D /raid/pg92data
>> 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
>> Creating catalog dump ok
>> Checking for presence of required libraries ok
>> Checking database user is a superuser ok
>> Checking for prepared transactions ok
>>
>> If pg_upgrade fails after this point, you must re-initdb the
>> new cluster before continuing.
>>
>> Performing Upgrade
>> ------------------
>> Analyzing all rows in the new cluster ok
>> Freezing all rows on the new cluster ok
>> Deleting files from new pg_clog ok
>> Copying old pg_clog to new server ok
>> Setting next transaction ID for new cluster ok
>> Resetting WAL archives ok
>> Setting frozenxid counters in new cluster ok
>> Creating databases in the new cluster ok
>> Adding support functions to new cluster ok
>> Restoring database schema to new cluster ok
>> Removing support functions from new cluster ok
>> Copying user relation files
>> /raid/pgsql/base/6087920/6088238
>> old and new databases "testdb" have a different number of relations
>> Failure, exiting
>
> That is an odd failure. That check was added in PG 9.1 and this is the
> first time I am seeing this failure.
>
> The check is to make sure that once we have created all the user schema
> details in the new cluster, that there are the same number of objects in
> the new and old databases.
>
> Obviously there are a different number in your case here, but I don't
> know why those would be different, and in fact, because we have never
> hit this, there isn't even any debug output that shows the source of the
> difference.
>
> If I send you a patch can you compile it and send back the debug output
> it produces?
>
Yes sure, I will try to compile and retest with it.