I have been testing pg_upgrade for
use migrating a PostgreSQL 8.4.2 cluster to PostgreSQL 9.0.1.
There is only one database (named
alerting) in this cluster and it has three tablespaces
defined:
CREATE TABLESPACE alerting_data
OWNER postgres LOCATION
'/pgdata/5432/pg_tblspc/alerting_data';
CREATE TABLESPACE alerting_index
OWNER postgres LOCATION
'/pgdata/5432/pg_tblspc/alerting_index';
CREATE TABLESPACE alerting_text
OWNER postgres LOCATION
'/pgdata/5432/pg_tblspc/alerting_text';
Following the directions in the
pg_upgrade documentation, I ran through the steps (I added step
6):
1. Performed a full backup with
pg_dumpall.
2. Stopped postmaster and all
backends.
3. Renamed old pgdata
directory.
4. Installed the new PostgreSQL
9.0.1 binaries
5. Ran initdb
(/usr/local/pgsql-9.0.1/bin/initdb -D
/pgdata/5432;)
6. I created all the existing (old)
tablespace directories and symlinks under the new pgdata
directory
7. Switched to the postgres user
and ran pg_upgrade, using:
/usr/local/pgsql-9.0.1/bin/pg_upgrade
-d /pgdata/5432.old -D /pgdata/5432 -b /usr/local/pgsql-8.4.2/bin -B
/usr/local/pgsql-9.0.1/bin -l /tmp/pg_upgrade.log;
During pg_upgrade's "Restoring user
relation files" step, when it encounters the first alerting object, it errors
out with:
“error while copying
public.ix_alert_createdategmt(/pgdata/5432/pg_tblspc/alerting_index/16616/17783)
to
public.ix_alert_createdategmt(/pgdata/5432/pg_tblspc/alerting_index/PG_9.0_201008051/16407/17783):
No such file or directory”
Is this a "bug" where pg_upgrade is
making an assumption about my use of version-specific subdirectories? Is there
a simple work-around (maybe changing our directory structure or alter tablespace
before the upgrade)?