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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +