Re: pg_migrator issue with contrib

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Brad Nicholson <bnichols(at)ca(dot)afilias(dot)info>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_migrator issue with contrib
Date: 2009-06-05 22:11:24
Message-ID: A16735F5-E29F-4B24-987D-B2D533375764@hi-media.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2009-06-05 22:24:24 Re: pg_migrator issue with contrib
Previous Message Joshua Tolley 2009-06-05 21:45:33 Re: Using results from DELETE ... RETURNING