Re: pg_migrator issue with contrib

Bruce Momjian wrote:
> > There is no nice answer to this. It goes way beyond data types: you 
> > could be using the module stuff in indexes, functions, views etc. You 
> > can't just drop the stuff. The best I have been able to do in similar 
> > cases is to install the updated module in the database before restoring, 
> > and ignore any restoration errors about "foo already exists" or "foo not 
> > found in .so file". Not sure how well that translates to pg_migrator, 
> > though.
> 
> I suspected this answer but figured I would get a definative answer
> rather than guessing.
> 
> Based on the way pg_migrator works I am going to suggest that if
> /contrib restore generates an error that they uninstall the /contrib
> from the old cluster and retry.

I have added the following paragraph to the pg_migrator INSTALL docs:
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 migration.
 

The only other idea I have would be to add a switch that allows
schema restore errors to be ignored, but I would like to see if the
above text is enough first.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +