Re: Re: [GENERAL] pg_upgrade fails, "mismatch of relation OID" - 9.1.9 to 9.2.4
От | Steve Singer |
---|---|
Тема | Re: Re: [GENERAL] pg_upgrade fails, "mismatch of relation OID" - 9.1.9 to 9.2.4 |
Дата | |
Msg-id | BLU0-SMTP92C937D23C1D145DB2F9E7DCA00@phx.gbl обсуждение исходный текст |
Ответ на | Re: Re: [GENERAL] pg_upgrade fails, "mismatch of relation OID" - 9.1.9 to 9.2.4 (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: Re: [GENERAL] pg_upgrade fails, "mismatch of
relation OID" - 9.1.9 to 9.2.4
|
Список | pgsql-hackers |
On 05/11/2013 04:58 PM, Bruce Momjian wrote: > On Fri, May 10, 2013 at 08:03:38PM -0400, Bruce Momjian wrote: >> 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. > I once saw a case where a varchar(x) column was changed to something larger by manually updating the catalog with an UPDATE statement on pg_attribute.atttypmod. Everything was fine until they tried pg_upgrade which failed because the DDL to create the table from pg_dump with the larger column creates a table that had a toast table but the original table in the 8.3 cluster did not have a toast table. Steve
В списке pgsql-hackers по дате отправления: