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 <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
