> 2020年4月15日 上午2:00，Alvaro Herrera <alvherre@2ndquadrant.com> 写道：
>
> On 2020-Apr-14, wenjing wrote:
>
>> However, if such a table exists, an error with pg_upgrade is further raised
>>
>> ./initdb -k -D datanew
>> ./pg_upgrade -d data -d datanew - b. -b.
>>
>> Restoring database schemas in the new cluster
>> postgres
>> *failure*
>>
>> Consult the last few lines of "pg_upgrade_dump_13580.log" for
>> the probable cause of the failure.
>> Failure, exiting
>>
>> pg_restore: from TOC entry 200; 1259 13581 TABLE t_create_by_standalone wenjing
>> pg_restore: error: could not execute query: ERROR: pg_type array OID value not set when in binary upgrade mode
>
> Maybe the solution is to drop the table before pg_upgrade.
>
> (Perhaps in --check mode pg_upgrade could warn you about such
> situations. But then, should it warn you specifically about random
> other instances of catalog corruption?)
I fixed the problem along your lines.
Please check.
Wenjing
>
> --
> Álvaro Herrera https://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
