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

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Jeff Ross <jeff(at)commandprompt(dot)com>
Cc: 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 19:00:03
Message-ID: 20140523190003.GB8484@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, May 23, 2014 at 08:32:35AM -0600, Jeff Ross wrote:
>
> On 5/23/14, 7:21 AM, Bruce Momjian wrote:
> >
> >On Thu, May 22, 2014 at 09:20:38AM -0600, Jeff Ross wrote:
> >>>I just tested ALTER TABLE in 8.4 and it does create a toast table for
> >>>this case in 9.4:
> >>>
> >>> CREATE TABLE test (x CHAR(10));
> >>> ALTER TABLE test ALTER COLUMN x TYPE CHAR(8000);
> >>>
> >>I just tried this on the problem table and it did indeed create a
> >>toast table.
> >>
> >>I then retried pg_upgrade and it failed with the same problem on a
> >>different table in the same database. Of the 67 databases in the
> >>8.4 cluster, 5 (so far) have had this problem on at least one table.
> >
> >Yeah, it would be nice to be able to report all the problem tables, but
> >I don't know how to do that except from pg_upgrade failing. Is there
> >anything similar about these tables?
> >
>
>
> Here are the last 2 tables I had a problem with:

Both have character varying fields, which supports the idea that the
field length might have been modified in pg_attribute.

--
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 Bruce Momjian 2014-05-23 19:02:15 Re: pg_upgrade fails: Mismatch of relation OID in database 8.4 -> 9.3
Previous Message Bruce Momjian 2014-05-23 18:59:24 Re: Re: pg_upgrade fails: Mismatch of relation OID in database 8.4 -> 9.3