| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | wenjing <wjzeng2012(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)lists(dot)postgresql(dot)org, tushar <tushar(dot)ahuja(at)enterprisedb(dot)com> |
| Subject: | Re: [bug] Table not have typarray when created by single user mode |
| Date: | 2020-04-14 18:00:19 |
| Message-ID: | 20200414180019.GA16161@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
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?)
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Iipponen Timo | 2020-04-14 20:14:10 | GRANT CONNECT statements not shown after pg_dump - pg_restore from PostgreSQL 9 to PostgreSQL 12 |
| Previous Message | PG Bug reporting form | 2020-04-14 17:12:47 | BUG #16362: yum repo: duplicated definition |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2020-04-14 18:43:35 | Re: index paths and enable_indexscan |
| Previous Message | David Steele | 2020-04-14 17:33:44 | Re: documenting the backup manifest file format |