From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | 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 20:18:34 |
Message-ID: | 200906052018.n55KIYO29232@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
> >> At the very least, a mention in the documentation of incompatible
> >> contrib module(s) would be nice. Even better would be a sanity check
> >> added to prevent this.
> >>
> >
> > OK, I am looking to the hackers group for recommentations on this. I
> > wonder if I should recommend uninstalling /contrib modules before the
> > upgrade, but that is not possible for custom data types that have
> > columns already defined in the old cluster.
> >
> >
>
> 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.
--
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. +
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2009-06-05 20:19:35 | Re: pg_migrator issue with contrib |
Previous Message | Bruce Momjian | 2009-06-05 20:15:26 | Re: pg_migrator issue with contrib |