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)?