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 по дате отправления: