Dimitri Fontaine wrote:
> 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 :)
Very good point, and something I had not considered. I tried
uninstalling hstore and it gladly dropped any hstore columns!
I have updated the INSTALL instructions:
If an error occurs while restoring the database schema, pg_migrator willexit and you will have to revert to the old
clusteras outlined in step#10 below. To try pg_migrator again, you will need to modify the oldcluster so the
pg_migratorschema restore succeeds. If the problem is a/contrib module, you might need to uninstall the /contrib
modulefromthe old cluster and install it in the new cluster after the migration,assuming the module is not being used
tostore user data.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +