Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

Next:From: Tom LaneDate: 2009-12-31 03:54:00
Subject: Re: Status of plperl inter-sp calling
Previous:From: Bruce MomjianDate: 2009-12-31 03:33:32
Subject: Re: A third lock method

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group