pg_migrator issues
in [PgSql]
|
From: Tom Lane on 5 Jan 2010 11:10 Robert Haas <robertmhaas(a)gmail.com> writes: > On Tue, Jan 5, 2010 at 11:06 AM, Alvaro Herrera > <alvherre(a)commandprompt.com> wrote: >> Tom Lane wrote: >>> Good point. �Using catversion for the purpose seems a bit ugly but >>> I have no better ideas. >> >> I thought we had rejected the idea of being able to migrate between >> alphas. �Is migrating between major versions not difficult enough? > We like a challenge. The problem with using just major version there is that then we are *wiring into the on-disk representation* the assumption that pg_migrator only goes from one major version to the next. I agree that we're not likely to start supporting cross-alpha-version migration any time soon, but I don't think it's wise to foreclose the possibility of ever doing it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 5 Jan 2010 11:22 Tom Lane wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: > > On Tue, Jan 5, 2010 at 11:06 AM, Alvaro Herrera > > <alvherre(a)commandprompt.com> wrote: > >> Tom Lane wrote: > >>> Good point. �Using catversion for the purpose seems a bit ugly but > >>> I have no better ideas. > >> > >> I thought we had rejected the idea of being able to migrate between > >> alphas. �Is migrating between major versions not difficult enough? > > > We like a challenge. > > The problem with using just major version there is that then we are > *wiring into the on-disk representation* the assumption that pg_migrator > only goes from one major version to the next. I agree that we're not > likely to start supporting cross-alpha-version migration any time soon, > but I don't think it's wise to foreclose the possibility of ever doing > it. I know people are trying to make things easier on pg_migrator, but frankly going from alpha to alpha does not require any new code in pg_migrator. And pg_migrator already supports cross-alpha-version migration just using the existing code --- no new code was added to enable this. -- Bruce Momjian <bruce(a)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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 5 Jan 2010 16:00 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?) Yes, and it will still need that because we don't want to transfer over any of the system tables or pg_catalog files. -- Bruce Momjian <bruce(a)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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 5 Jan 2010 22:04 Bruce Momjian 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. > > Attached is a patch that implements #1 above by preserving all > relfilenodes, with pg_dump support. It uses the same method I used for > preserving pg_type/pg_enum. I have tested this on the regression > database and it successfully preserved all relfilenodes. > > This patch also removes the 'force' parameter in toast functions that > Tom added for 8.4 --- it is no longer needed. Applied. -- Bruce Momjian <bruce(a)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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 5 Jan 2010 22:05
Bruce Momjian wrote: > Alvaro Herrera wrote: > > > 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 > > OK, I have implemented this using --only-analyze to avoid having the > '--anal' option spelling be ambiguous, which might confuse/frustrate > users. > > I also moved the --freeze option documention mention into a more logical > place. > > Patch attached. Applied. -- Bruce Momjian <bruce(a)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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |