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  (Bruce Momjian <bruce@momjian.us>)
Re: pg_migrator issues  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: pg_migrator issues  (Bruce Momjian <bruce@momjian.us>)
Re: pg_migrator issues  (Bruce Momjian <bruce@momjian.us>)
Re: pg_migrator issues  (decibel <decibel@decibel.org>)
Re: pg_migrator issues  (Bruce Momjian <bruce@momjian.us>)
Re: pg_migrator issues  (Bruce Momjian <bruce@momjian.us>)
Re: pg_migrator issues  (Bruce Momjian <bruce@momjian.us>)
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:

Previous
From: Bruce Momjian
Date:
Subject: Re: A third lock method
Next
From: Tom Lane
Date:
Subject: Re: Status of plperl inter-sp calling