Re: pg_migrator issues

Alvaro Herrera wrote:
> 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?)

Yea, as Tom said later, there are two options. Either we create
placeholder files and then remove the place-holders when we create the
toast tables or we just preserve all relfilenodes --- I think the later
is easier.

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

Well, I am not much into 'safety margins' with pg_migrator, meaning I
want to get the most reliable value I can --- I have no idea what that
safety margin would be. Right now pg_migrator works fine by calling
pg_controldata or pg_resetxlog as appropriate. I was hoping to allow
pg_resetxlog -n on a live server. Is that something we should avoid?
I really don't need the change --- it would just simplify pg_migrator.

I was just really asking if disallowing pg_resetxlog -n on a live server
is planned behavior or an oversight. I can see the logic that it should
be disallowed but I am just looking for confirmation from someone and I
can then drop the issue.

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