Re: pg_migrator issue with contrib
От | Dimitri Fontaine |
---|---|
Тема | Re: pg_migrator issue with contrib |
Дата | |
Msg-id | A16735F5-E29F-4B24-987D-B2D533375764@hi-media.com обсуждение исходный текст |
Ответ на | Re: pg_migrator issue with contrib (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: pg_migrator issue with contrib
Re: pg_migrator issue with contrib |
Список | pgsql-hackers |
Hi, Ah, we need module/extension/package/plugin so badly... Le 5 juin 09 à 22:19, Bruce Momjian a écrit : > I am afraid /contrib is going to be a mine field for this type of > problem so I am going to recommend uninstaling the /contrib module if > possible and retry the migration. That should work in this case. You can't seriously recommend that, I'm afraid. As Andrew (Dunstan) was saying up-thread, the faulty module (from contrib or pgfoundry) could hold some indexes (btree, gist, gin) and/ or data types in the cluster relations. So if you uninstall the module (drop type cascade, drop operator class, ...) you lose data. Some example modules that I can think of and are wildspread in the field, as far as I know, are ip4r (data type and indexes), orafce (functions, views, tables), and some less spread are prefix (data type and indexes) or temporal (period data type, indexes). Please do not recommend people to lose their precious data to be able to upgrade. You could tell them pg_migrator isn't an option in their case, though. At least we're left with a faster (multi-threaded) pg_restore :) Regards, -- dim
В списке pgsql-hackers по дате отправления: