pg_upgrade fails: Mismatch of relation OID in database 8.4 -> 9.3

From: Jeff Ross <jeff(at)commandprompt(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: pg_upgrade fails: Mismatch of relation OID in database 8.4 -> 9.3
Date: 2014-05-20 18:59:31
Message-ID: 537BA613.4090804@commandprompt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2014-05-20 19:03:27 Re: jsonb failed assertions
Previous Message Peter Geoghegan 2014-05-20 18:53:53 Re: jsonb failed assertions