Re: [bug] Table not have typarray when created by single user mode

> 2020年4月13日 下午10:51，Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 写道：
>
> wenjing <wjzeng2012(at)gmail(dot)com> writes:
>> Use single user mode (t_create_by_standalone) typarray = 0, but use psql t_create_by_psql typarray has oid.
>
> That's because of this in heap_create_with_catalog:
>
> /*
> * Decide whether to create an array type over the relation's rowtype. We
> * do not create any array types for system catalogs (ie, those made
> * during initdb). We do not create them where the use of a relation as
> * such is an implementation detail: toast tables, sequences and indexes.
> */
> if (IsUnderPostmaster && (relkind == RELKIND_RELATION ||
> relkind == RELKIND_VIEW ||
> relkind == RELKIND_MATVIEW ||
> relkind == RELKIND_FOREIGN_TABLE ||
> relkind == RELKIND_COMPOSITE_TYPE ||
> relkind == RELKIND_PARTITIONED_TABLE))
> new_array_oid = AssignTypeArrayOid();
>
> Admittedly, "!IsUnderPostmaster" is not exactly the same thing as "running
> during initdb", but I do not consider this a bug. You generally should
> not be using single-user mode for anything except disaster recovery.
>
> regards, tom lane

Thanks for explain. I can understand your point.

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
Command was:
-- For binary upgrade, must preserve pg_type oid
SELECT pg_catalog.binary_upgrade_set_next_pg_type_oid('13582'::pg_catalog.oid);

I wonder if there are any restrictions that need to be put in somewhere?

Wenjing