Re: [bug] Table not have typarray when created by single user mode
От | wenjing |
---|---|
Тема | Re: [bug] Table not have typarray when created by single user mode |
Дата | |
Msg-id | 9FCD07FF-CAF6-4220-8E07-E4E8037D6899@gmail.com обсуждение исходный текст |
Ответ на | Re: [bug] Table not have typarray when created by single user mode (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [bug] Table not have typarray when created by single user mode
|
Список | pgsql-bugs |
2020年4月13日 下午10:51,Tom Lane <tgl@sss.pgh.pa.us> 写道:wenjing <wjzeng2012@gmail.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
В списке pgsql-bugs по дате отправления: