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

From Steve Singer
Subject Re: Re: [GENERAL] pg_upgrade fails, "mismatch of relation OID" - 9.1.9 to 9.2.4
Date
Msg-id BLU0-SMTP92C937D23C1D145DB2F9E7DCA00@phx.gbl
Whole thread Raw
In response to Re: Re: [GENERAL] pg_upgrade fails, "mismatch of relation OID" - 9.1.9 to 9.2.4  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Re: [GENERAL] pg_upgrade fails, "mismatch of relation OID" - 9.1.9 to 9.2.4
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: corrupt pages detected by enabling checksums
Next
From: Jon Nelson
Date:
Subject: Re: corrupt pages detected by enabling checksums