From: Bruce Momjian <bruce@momjian.us>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Bernhard Schrader <bernhard.schrader@innogames.de>
Cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [ADMIN] Problems with enums after pg_upgrade
Date: Tue, 18 Dec 2012 11:22:56 -0500
Message-ID: <20121218162256.GA24700@momjian.us> (raw)
In-Reply-To: <50D0914E.3040508@dunslane.net>
References: <50CEFE95.9040301@innogames.de>
<20121218014137.GB29143@momjian.us>
<50D02D13.3010004@innogames.de>
<50D0914E.3040508@dunslane.net>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On Tue, Dec 18, 2012 at 10:52:46AM -0500, Andrew Dunstan wrote:
> The translations from oid to label are in pg_enum, but it looks like
> somehow you have lost that mapping. I'm not sure what you've done
> but AFAICT pg_upgrade is doing the right thing.
>
> I just did this (from 9.0 to 9.2) and the pg_upgrade_dump_all.sql
> that is used to create the new catalog has these lines:
>
> -- For binary upgrade, must preserve pg_type oid
> SELECT binary_upgrade.set_next_pg_type_oid('40804'::pg_catalog.oid);
>
>
> -- For binary upgrade, must preserve pg_type array oid
> SELECT
> binary_upgrade.set_next_array_pg_type_oid('40803'::pg_catalog.oid);
>
> CREATE TYPE myenum AS ENUM (
> );
>
> -- For binary upgrade, must preserve pg_enum oids
> SELECT binary_upgrade.set_next_pg_enum_oid('40805'::pg_catalog.oid);
> ALTER TYPE public.myenum ADD VALUE 'foo';
>
> SELECT binary_upgrade.set_next_pg_enum_oid('40806'::pg_catalog.oid);
> ALTER TYPE public.myenum ADD VALUE 'bar';
>
> SELECT binary_upgrade.set_next_pg_enum_oid('40807'::pg_catalog.oid);
> ALTER TYPE public.myenum ADD VALUE 'baz';
>
> and this worked exactly as expected, with a table using this type
> showing the expected values.
>
> Can you produce a test case demonstrating the error?
>
> When you run pg_upgrade, use the -r flag to keep all the
> intermediate files so we can see what's going on.
>
> It's no good dumping the new db looking for these values if they
> have been lost. You would need to have a physical copy of the old db
> and dump that in binary upgrade mode looking for the Oid. If you
> don't have a physical copy of the old db or the intermediate dump
> file pg_upgrade used then recovery is going to be pretty difficult.
> It's not necessarily impossible, but it might involve you getting
> some outside help.
Yes, this matches what I thought too. You see the
binary_upgrade.set_next_pg_enum_oid() calls in pg_dump --binary-upgrade
--schema-only and those set the oid of the newly created enum.
I agree you would need to run this on the _old_ cluster for us to figure
out how it failed.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: bruce@momjian.us, andrew@dunslane.net, bernhard.schrader@innogames.de, pgsql-hackers@postgreSQL.org
Subject: Re: [ADMIN] Problems with enums after pg_upgrade
In-Reply-To: <20121218162256.GA24700@momjian.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox