Robert Haas wrote: > >> 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.
I considered that but realize that pg_migrator has to read pg_controldata in both the old and new servers, meaning it would need access to both C structures, and considering they both have the same structure names, that would require some odd C tricks. Add to that you don't know which version of Postgres you are migrating from/to during compile and the idea of using C becomes even less attractive. Doing this in C would require pg_migrator to track all changes in the pg_controldata structure layout, which seems excessively complex/error-prone. Right now I only have to track changes to the naming of the output fields. -- 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
