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

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Christoph Berg <christoph(dot)berg(at)credativ(dot)de>, PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: pg_upgrade 9.0->9.2 failure: Mismatch of relation OID in database
Date: 2013-10-02 17:06:28
Message-ID: 20131002170628.GC5960@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, Sep 26, 2013 at 02:59:30PM +0200, Christoph Berg wrote:
> 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
> );

That is very interesting, and it certainly should not be failing.

I am surprised it got an oid that was one less than the desired one,
18803. Is there any mention of 18803 in the SQL file? If you create a
cluster with just your schema and no data, can you upgrade that cleanly?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andres Freund 2013-10-03 16:11:39 abort()/segfault when starting postgres in inaccessible CWD
Previous Message Bruce Momjian 2013-10-02 16:19:46 Re: BUG #8469: Xpath behaviour unintuitive / arguably wrong