Re: pg_migrator issue with contrib - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: pg_migrator issue with contrib
Date
Msg-id A16735F5-E29F-4B24-987D-B2D533375764@hi-media.com
Whole thread Raw
In response to Re: pg_migrator issue with contrib  (Bruce Momjian <bruce@momjian.us>)
Responses Re: pg_migrator issue with contrib
Re: pg_migrator issue with contrib
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: blocking referencing system catalogs in 8.4 breaks my code
Next
From: Josh Berkus
Date:
Subject: Re: pg_migrator issue with contrib