pg_migrator issues

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. +

Responses

Browse pgsql-hackers by date

  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