From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Murthy Nunna <mnunna(at)fnal(dot)gov> |
Cc: | "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: pg_upgrade failure upgrading from v10.8 to v14.4 |
Date: | 2022-07-22 16:30:32 |
Message-ID: | CAKFQuwYKaU7eOpO2Z++TuDZX4GzVYmbgPpm0wdoRmW_O=FyGwQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Fri, Jul 22, 2022 at 9:19 AM Murthy Nunna <mnunna(at)fnal(dot)gov> wrote:
>
> I encountered following error. Any help or insight is much appreciated.
>
>
> CREATE VIEW "public"."all_tables" AS
>
> SELECT ((("n"."nspname")::"text" || '.'::"text") ||
> ("c"."relname")::"text") AS "tablename",
>
>
>
You created a view that uses the catalogs and the structure of those
catalogs has changed. pg_upgrade cannot fix this for you. Unfortunately,
the only real solution is to have a pre-upgrade script that removes the not
unusable view, perform the upgrade, and then run a post-upgrade script that
replaces it with something that will work in the new system. I'm unaware
of a version of PostgreSQL that would act as a transition version where
both versions of the view could exist, but you may wish to double-check
that if you think such a two-step upgrade path would be easier for you to
manage.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | MichaelDBA Vitale | 2022-07-22 17:13:01 | Re: pg_upgrade failure upgrading from v10.8 to v14.4 |
Previous Message | Murthy Nunna | 2022-07-22 16:19:42 | pg_upgrade failure upgrading from v10.8 to v14.4 |