Re: pg_upgrade fails: Mismatch of relation OID in database 8.4 -> 9.3

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeff Ross <jeff(at)commandprompt(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade fails: Mismatch of relation OID in database 8.4 -> 9.3
Date: 2014-05-23 14:09:35
Message-ID: 20140523140935.GA7646@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 22, 2014 at 09:55:10AM -0400, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > Moving forward, I think you need to add a dummy column to each problem
> > table and drop the column ---- that will create a toast table and allow
> > you to do the upgrade. I could have pg_upgrade detect this problem, but
> > until I know the cause, I don't think that is wise.
>
> Maybe --check mode could examine both clusters and see whether each
> table having toast table or not matches. That wouldn't solve the actual
> problem but at least give a clue, instead of these very obscure
> problems.

There is no way to check for an old/new toast mismatch except creating
the tables on the new cluster, and check mode can't do that due to time
and because it would modify the new cluster and make it non-upgradeable.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2014-05-23 14:10:23 Re: wrapping in extended mode doesn't work well with default pager
Previous Message Tom Lane 2014-05-23 14:01:37 Re: -DDISABLE_ENABLE_ASSERT