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

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.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +