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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
