pg_upgrade fails: Mismatch of relation OID in database 8.4 -> 9.3 - Mailing list pgsql-hackers

Hi all,

I'm trying to pg_upgrade an 8.4.21 to 9.3.4.

The is on Debian 7--both versions were installed from apt.postgresql.org 
and are encoding "UTF8" and locale "C".

Here's the error:

/usr/lib/postgresql/9.3/bin/pg_upgrade \        -b /usr/lib/postgresql/8.4/bin/ \        -B
/usr/lib/postgresql/9.3/bin/\        -d /var/lib/postgresql/8.4/main/ \        -D /var/lib/postgresql/9.3/main/ \
-p5433 \        -P5432 \        -u postgres \        -o "-c config_file=/etc/postgresql/8.4/main/postgresql.conf" \
  -O "-c config_file=/etc/postgresql/9.3/main/postgresql.conf"
 
Performing Consistency Checks
-----------------------------
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                                  warning

Your installation contains large objects.  The new database has an
additional large object permission table.  After upgrading, you will be
given a command to populate the pg_largeobject permission table with
default permissions.

Creating dump of global objects                             ok
Creating dump of database schemas                                                            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
Setting oldest multixact ID on new cluster                  ok
Resetting WAL archives                                      ok
Setting frozenxid counters in new cluster                   ok
Restoring global objects in the new cluster                 ok
Adding support functions to new cluster                     ok
Restoring database schemas in the new cluster                                                            ok
Removing support functions from new cluster                 ok
Copying user relation files  /var/lib/postgresql/8.4/main/base/4275487/4278965
Mismatch of relation OID in database "FNBooking": old OID 4279499, new 
OID 19792
Failure, exiting

On 8.4.21, here's that OID:

postgres=# \c "FNBooking"
psql (9.3.4, server 8.4.21)
You are now connected to database "FNBooking" as user "postgres".
FNBooking=# SELECT relname, relfilenode, relkind from pg_class where oid 
= 4279499;    relname    | relfilenode | relkind
---------------+-------------+--------- abandone_conv |     4279499 | r
(1 row)

and on 9.3.4 it is the same:

postgres@vdev1commandprompt2:~$ psql "FNBooking"
psql (9.3.4)
Type "help" for help.

FNBooking=# SELECT relname, relfilenode, relkind from pg_class where oid 
= 4279499;    relname    | relfilenode | relkind
---------------+-------------+--------- abandone_conv |     4279499 | r
(1 row)

On 8.4.21, the new OID doesn't exist:

FNBooking=# SELECT relname, relfilenode, relkind from pg_class where oid 
= 19792; relname | relfilenode | relkind
---------+-------------+---------
(0 rows)

and on 9.3.4 it is this:

FNBooking=# SELECT relname, relfilenode, relkind from pg_class where oid 
= 19792;     relname      | relfilenode | relkind
------------------+-------------+--------- pg_toast_4279527 |       19792 | t
(1 row)

Just to check, I did a pg_dump of the 8.4.21 FNBooking database and it 
restored with psql to 9.3.4 with no issues but the overall migration 
will really be too big to go this route.

Any ideas?

Thanks!

Jeff Ross