From: | Palle Girgensohn <girgen(at)pingpong(dot)net> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | pg_upgrade fails in 9.6 beta1 |
Date: | 2016-05-16 15:07:25 |
Message-ID: | 1739E340-ECA4-4042-B971-7B31F658B51C@pingpong.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
When trying an upgrade from postgresql94 -> postgresql96 (beta1) using pg_upgrade:
pg_upgrade -p 5433 -P 5434 -b /usr/local/bin -B /home/girgen/postgres96/bin -d /tank/opt96/pgsql/data94 -D /tank/opt96/pgsql/data96 -U pgsql96 -k
I eventually get this:
pg_restore: creating TABLE "public.cal_event"
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 205; 1259 3538451239 TABLE cal_event nobody
pg_restore: [archiver (db)] could not execute query: ERROR: could not create directory "pg_tblspc/16400/PG_9.4_201605051/16403": No such file or directory
Command was:
-- For binary upgrade, must preserve pg_type oid
SELECT pg_catalog.binary_upgrade_set_next_pg_type_oid('3538451241'::pg_cat...
now
"pg_tblspc/16400/PG_9.4_201605051/16403"
is a mixup of the new cluster pg_tblspc/16400, the old version PG_9.4_, and the new cluster 201605051/
that is, pg_upgrade seems to take the old version as a parameter ( PG_9.4_ ) when trying to create the new tablespace.
This happens in pg_restore, it seems:
Restoring database schemas in the new cluster
loadtest
*failure*
Seems like a bug to me, it shouldn't create pg_tblspc/16400/PG_9.4_201605051, the 9.6 tablespace is in data96/pg_tblspc/16400/PG_9.6_201605051 (not 9.4).
Palle
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-05-16 15:25:11 | Re: Optimization for updating foreign tables in Postgres FDW |
Previous Message | Robert Haas | 2016-05-16 14:49:13 | Re: Reviewing freeze map code |