Re: pg_migrator issues

Bruce,

Sorry for not having replied sooner...

On Sun, Jan 3, 2010 at 5:43 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> 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.

I have no opinion on this one way or the other.

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

I don't really like this. It seems klunky, and it seems like there
ought to be a way to avoid needing to rename the tablespace
directories at all.

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

Something like vacuumdb --analyze-only? It seems like overkill to
create a whole new command for this, even though vacuumdb doesn't
quite make sense.

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

I don't really have a specific thought on this issue, except that it
sounds like you're launching a lot of shell commands, and I wonder
whether it would be better to try to do this through either C code or
by exposing the appropriate stuff at the SQL level.

...Robert