From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | pg_migrator issues |
Date: | 2009-12-31 03:50:11 |
Message-ID: | 200912310350.nBV3oBW15298@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
pg_migrator has become more popular recently, so it seems time to look
at some enhancements that would improve pg_migrator. None of these are
required, but rather changes that would be nice to have:
1) Right now pg_migrator preserves relfilenodes for TOAST files because
this is required for proper migration. Now that we have shown that
strategically-placed global variables with a server-side function to set
them is a viable solution, it would be nice to preserve all relfilenodes
from the old server. This would simplify pg_migrator by no long
requiring place-holder relfilenodes or the renaming of TOAST files. A
simpler solution would just be to allow TOAST table creation to
automatically remove placeholder files and create specified relfilenodes
via global variables.
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.
3) There is no easy way to analyze all databases. vacuumdb --analyze
does analyze _and_ vacuum, which for an 8.4 to 8.5 migration does an
unnecessary vacuum. Right now I recommend ANALYZE in every database,
but it would be nice if there were a single command which did this.
4) I have implemented the ability to run pg_migrator --check on a live
old server. However, pg_migrator uses information from controldata to
check things, and it also needs xid information that is only available
via pg_resetxlog -n(no update) to perform the migration. Unfortunately,
pg_resetxlog -n cannot be run on a live server, so pg_migrator runs
pg_controldata for --check and pg_resetxlog -n for real upgrades. It
would simplify pg_migrator if I would run pg_resetxlog -n on a live
server, but I can understand if people don't want to do that because the
xid information reported on a live server is inaccurate.
Comments?
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-12-31 03:54:00 | Re: Status of plperl inter-sp calling |
Previous Message | Bruce Momjian | 2009-12-31 03:33:32 | Re: A third lock method |