Re: pg_migrator issue with contrib

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 will
exit and you will have to revert to the old cluster as outlined in step
#10 below. To try pg_migrator again, you will need to modify the old
cluster so the pg_migrator schema restore succeeds. If the problem is a
/contrib module, you might need to uninstall the /contrib module from
the old cluster and install it in the new cluster after the migration,
assuming the module is not being used to store user data.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +