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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
