From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: pg_migrator issues |
Date: | 2010-01-04 15:14:06 |
Message-ID: | 20100104151406.GC3778@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian wrote:
> 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.
Getting rid of the need for placeholders is a good idea. +1 on getting
TOAST tables created with the correct relfilenode from the start. I
don't know that preserving any other relfilenode is useful; however if
it means you no longer have to rename the files underlying each table,
it would probably also be a good idea. (I don't know how does
pg_migrator deal with such things currently -- does it keep a map of
table name to relfilenode?)
> 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.
I thought it was impossible to use bare mountpoints as tablespaces due
to ownership problems ... Is that not the case? -1 for special hacks
that work around bogus setups, if that means intrusive changes to the
core code.
> 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.
+1 for vacuumdb --analyze-only
> 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.
What xid info does it need? Would it be good enough to use the "next
XID" from most recent checkpoint from pg_controldata? It is a bit
outdated, but can't you simply add some value to it to have a safety margin?
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-01-04 15:18:45 | Re: pg_migrator issues |
Previous Message | Tom Lane | 2010-01-04 15:11:24 | Re: invalid UTF-8 via pl/perl |