Re: Re: [GENERAL] pg_upgrade fails, "mismatch of relation OID" - 9.1.9 to 9.2.4

From: "Evan D(dot) Hoffman" <evandhoffman(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Igor Neyman <ineyman(at)perceptron(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: [GENERAL] pg_upgrade fails, "mismatch of relation OID" - 9.1.9 to 9.2.4
Date: 2013-05-13 02:43:41
Message-ID: CABRB-LsHGXM_XuwjHv8TQwPdRXfRm2tY58q63aGK1Ggvg+gdkw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Adding & dropping a column resolved the problem. Currently vacuuming the
new cluster. Thanks for your help everybody!

On Sat, May 11, 2013 at 4:58 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> On Fri, May 10, 2013 at 08:03:38PM -0400, Bruce Momjian wrote:
> > On Fri, May 10, 2013 at 12:36:21PM -0400, Evan D. Hoffman wrote:
> > > "........pg.dropped.16........" INTEGER /* dummy */,
> > > "........pg.dropped.17........" INTEGER /* dummy */,
> > > "........pg.dropped.18........" INTEGER /* dummy */,
> > > "........pg.dropped.19........" INTEGER /* dummy */,
> > > "........pg.dropped.20........" INTEGER /* dummy */,
> > > "........pg.dropped.21........" INTEGER /* dummy */,
> > > "........pg.dropped.22........" INTEGER /* dummy */,
> > > "........pg.dropped.23........" INTEGER /* dummy */,
> > > "........pg.dropped.24........" INTEGER /* dummy */,
> > > "........pg.dropped.25........" INTEGER /* dummy */,
> > > "........pg.dropped.26........" INTEGER /* dummy */,
> > > ha27 character varying(10) DEFAULT 'UNKNOWN'::character varying,
> > > "........pg.dropped.28........" INTEGER /* dummy */,
> > > dr29 character varying(10)
> >
> > OK, this verifies that the table had a lot of DDL churn. I have no idea
> > how to pursue this further because I am unsure how we are going to
> > replicate the operations performed on this table in the past, as you
> > mentioned much of this was before your time on the job.
> >
> > Evan, I suggest you force a toast table on the table by doing:
> >
> > ALTER TABLE bpm.setupinfo ADD COLUMN dummy TEXT;
> >
> > Then drop the column. That will create a toast table and will allow
> > pg_upgrade to succeed.
>
> FYI, I did test adding a TEXT column and altering a column to TEXT on
> Postgres 9.1, and both created a toast table. I am still have no clues
> about what would have caused the missing toast table.
>
> --
> Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + It's impossible for everything to be true. +
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tsunakawa, Takayuki 2013-05-13 04:20:53 In what situations do you use -U of initdb?
Previous Message John R Pierce 2013-05-13 01:58:29 Re: Deploying PostgreSQL on CentOS with SSD and Hardware RAID

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2013-05-13 03:07:27 Re: Fast promotion failure
Previous Message amul sul 2013-05-13 01:51:56 Re: psql connection reset failed