Re: [ADMIN] Problems with enums after pg_upgrade

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: [ADMIN] Problems with enums after pg_upgrade
Дата
Msg-id 20121218162256.GA24700@momjian.us
обсуждение исходный текст
Ответ на Re: [ADMIN] Problems with enums after pg_upgrade  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: [ADMIN] Problems with enums after pg_upgrade
Список pgsql-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. +



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: [ADMIN] Problems with enums after pg_upgrade
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [GENERAL] trouble with pg_upgrade 9.0 -> 9.1