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  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Leonardo Lao
Дата:
Сообщение: Error al iniciar postgresql con /etc/init.d/postgresql start
Следующее
От: ChiJin Zhou
Дата:
Сообщение: Buffer overflow when continuously send SIGHUP to postgres