Bruce Momjian wrote:
> 2) Right now pg_migrator renames old tablespaces to .old, which fails
> if the tablespaces are on mount points. I have already received a
> report of such a failure. $PGDATA also has that issue, but that
> renaming has to be done by the user before pg_migrator is run, and only
> if they want to keep the same $PGDATA value after migration, i.e. no
> version-specific directory path. One idea we floated around was to have
> tablespaces use major version directory names under the tablespace
> directory so renaming would not be necessary. I could implement a
> pg_migrator --delete-old flag to cleanly delete the old 8.4 server files
> which are not in a version-specific subdirectory.
FYI, pg_migrator CVS now uses the relfilenode preservation ability in
8.5 to avoid the creation of placeholder relfilenodes and renaming. It
also recommends using vacuumdb --only-analyze.
To simplify pg_migrator, you can now only migrate _to_ 8.5 as of today's
CVS, not earlier 8.5 CVS trees. One interesting aspect of pg_migrator
is that while it has to carry around support for upgrading _from_ many
old releases, the target/to version support can stay limited, i.e. I
doubt anyone is going to want to use pg_migrator to migrate to 8.4 in a
year or two --- they will be migrating to 8.5. We can also consider
removing 8.4 target migration support in pg_migrator 8.5 and just tell
people they have to use pg_migrator 8.4.X for a migration to PG 8.4.X.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
