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  (Bruce Momjian <bruce@momjian.us>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: corrupt pages detected by enabling checksums
Следующее
От: Jon Nelson
Дата:
Сообщение: Re: corrupt pages detected by enabling checksums