pg_upgrade 9.0->9.2 failure: Mismatch of relation OID in database

From: Christoph Berg <christoph(dot)berg(at)credativ(dot)de>
To: PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: pg_upgrade 9.0->9.2 failure: Mismatch of relation OID in database
Date: 2013-09-26 12:59:30
Message-ID: 20130926125930.GC13133@msgid.df7cb.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On upgrading a 9.0 database to 9.2 using pg_upgrade, I got this:

# pg_upgradecluster -m upgrade 9.0 main /psql/data-9.2
[...]
Performing Upgrade
------------------
[...]
Restoring database schema to new cluster ok
Removing support functions from new cluster ok
Copying user relation files

Mismatch of relation OID in database "hisrm": old OID 18804, new OID 18803
Failure, exiting
Error: pg_upgrade run failed

This is a cluster that was running with 9.0.12 (compiled locally). For
the upgrade, I installed postgresql-9.0 and -9.2 from
apt.postgresql.org (9.0.13, 9.2.4), so pg_upgrade was using these
versions. OS is Ubuntu 12.04 amd64 now and was 8.04 while the cluster
was still running on 9.0.12.

In the 9.0 cluster, 18804 is the relation oid of glm_lrahm_to_se.

pg_upgrade_dump_all.sql:
--
-- Name: glm_lrahm_to_se; Type: TABLE; Schema: mbs; Owner: fsv; Tablespace:
--

-- For binary upgrade, must preserve pg_type oid
SELECT binary_upgrade.set_next_pg_type_oid('18806'::pg_catalog.oid);

-- For binary upgrade, must preserve pg_type array oid
SELECT binary_upgrade.set_next_array_pg_type_oid('18805'::pg_catalog.oid);

-- For binary upgrade, must preserve pg_class oids
SELECT binary_upgrade.set_next_heap_pg_class_oid('18804'::pg_catalog.oid);

CREATE TABLE glm_lrahm_to_se (
id integer NOT NULL,
lrahm integer NOT NULL,
se integer NOT NULL
);

-- For binary upgrade, set heap's relfrozenxid
UPDATE pg_catalog.pg_class
SET relfrozenxid = '14118'
WHERE oid = 'glm_lrahm_to_se'::pg_catalog.regclass;

ALTER TABLE mbs.glm_lrahm_to_se OWNER TO fsv;

pg_upgrade_restore.sql:
SELECT binary_upgrade.set_next_pg_type_oid('18806'::pg_catalog.oid);
set_next_pg_type_oid
----------------------

(1 Zeile)

SELECT binary_upgrade.set_next_array_pg_type_oid('18805'::pg_catalog.oid);
set_next_array_pg_type_oid
----------------------------

(1 Zeile)

SELECT binary_upgrade.set_next_heap_pg_class_oid('18804'::pg_catalog.oid);
set_next_heap_pg_class_oid
----------------------------

(1 Zeile)

CREATE TABLE glm_lrahm_to_se (
id integer NOT NULL,
lrahm integer NOT NULL,
se integer NOT NULL
);
CREATE TABLE
UPDATE pg_catalog.pg_class
SET relfrozenxid = '14118'
WHERE oid = 'glm_lrahm_to_se'::pg_catalog.regclass;
UPDATE 1
ALTER TABLE mbs.glm_lrahm_to_se OWNER TO fsv;
ALTER TABLE

(I can provide more info on request.)

Christoph
--
cb(at)df7cb(dot)de | http://www.df7cb.de/

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message dnrickner 2013-09-26 15:22:40 BUG #8471: subquery where not being applied until outer query
Previous Message Stuart Bishop 2013-09-25 19:49:48 Re: BUG #8450: pg_basebackup blocks until WAL archiving successful