pg_migrator issues - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | pg_migrator issues |
Date | |
Msg-id | 200912310350.nBV3oBW15298@momjian.us Whole thread Raw |
Responses |
Re: pg_migrator issues
Re: pg_migrator issues Re: pg_migrator issues Re: pg_migrator issues Re: pg_migrator issues Re: pg_migrator issues Re: pg_migrator issues Re: pg_migrator issues |
List | 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@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
pgsql-hackers by date: