pg_migrator to /contrib in a later 9.0 beta
in [PgSql]
|
Prev: [HACKERS] pg_migrator to /contrib in a later 9.0 beta
Next: [HACKERS] failed assertion and panic in standby mode
From: Robert Haas on 5 May 2010 20:24 On Wed, May 5, 2010 at 7:44 PM, Bruce Momjian <bruce(a)momjian.us> wrote: > Alvaro Herrera wrote: >> >> So what was the conclusion here? Is pg_migrator going to be in contrib >> for beta2 or 3, after cleaning it up? > > Thanks for asking. :-) I can add pg_migrator to contrib by the end of > next week, so it will be in beta2. I will remove 8.4 as a migration > target, which will allow the removal of some C code and documentation > warnings. Unless I hear otherwise, I will start on it in the next few > days. Total work will be < 8 hours, including testing. > > One outstanding question is whether we want to rename pg_migrator to > something clearer, like pg_upgrade or pg_binary_upgrade. (pg_upgrade > was the original name for this migration method in the 1998.) I am > slightly concerned that the "migration" word is too associated with > cross-database-product migration. (There are no mentions of > "pg_migrator" in our CVS now, except for an 8.4 release note item > mention when pg_dump --binary-upgrade was added.) I think it will be confusing if we change the name, so I vote to not change the name. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- 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: "Joshua D. Drake" on 5 May 2010 22:14 On Wed, 2010-05-05 at 20:24 -0400, Robert Haas wrote: > On Wed, May 5, 2010 at 7:44 PM, Bruce Momjian <bruce(a)momjian.us> wrote: > > Alvaro Herrera wrote: > >> > >> So what was the conclusion here? Is pg_migrator going to be in contrib > >> for beta2 or 3, after cleaning it up? > > > > Thanks for asking. :-) I can add pg_migrator to contrib by the end of > > next week, so it will be in beta2. I will remove 8.4 as a migration > > target, which will allow the removal of some C code and documentation > > warnings. Unless I hear otherwise, I will start on it in the next few > > days. Total work will be < 8 hours, including testing. > > > > One outstanding question is whether we want to rename pg_migrator to > > something clearer, like pg_upgrade or pg_binary_upgrade. (pg_upgrade > > was the original name for this migration method in the 1998.) I am > > slightly concerned that the "migration" word is too associated with > > cross-database-product migration. (There are no mentions of > > "pg_migrator" in our CVS now, except for an 8.4 release note item > > mention when pg_dump --binary-upgrade was added.) > > I think it will be confusing if we change the name, so I vote to not > change the name. Actually, I would vote yes to change the name. Once its in contrib, we likely never will and this isn't really a migration tool. It is an upgrade tool. Joshua D. Drake > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise Postgres Company > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering -- 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: Tom Lane on 5 May 2010 22:36 "Joshua D. Drake" <jd(a)commandprompt.com> writes: > On Wed, 2010-05-05 at 20:24 -0400, Robert Haas wrote: >> I think it will be confusing if we change the name, so I vote to not >> change the name. > Actually, I would vote yes to change the name. I lean that way too. If there were no history involved, we'd certainly prefer pg_upgrade to pg_migrator. 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 May 2010 23:23 Tom Lane wrote: > "Joshua D. Drake" <jd(a)commandprompt.com> writes: > > On Wed, 2010-05-05 at 20:24 -0400, Robert Haas wrote: > >> I think it will be confusing if we change the name, so I vote to not > >> change the name. > > > Actually, I would vote yes to change the name. > > I lean that way too. If there were no history involved, we'd certainly > prefer pg_upgrade to pg_migrator. Yeah, that was my feeling too. People like "pg_upgrade", or something else? I will add some text like "pg_upgrade (formerly pg_migrator)" in the docs. I will also add something about the fact that there is no guarantee that pg_upgrade will work with all future major Postgres releases, per Tom's concern. FYI, I specifically labeled backend changes as "binary upgrade" because I wanted to make sure those changes were useful for other binary upgrade tools, in case someone wanted to create another one. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com -- 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: Jesper Krogh on 6 May 2010 00:32
On 2010-05-06 01:45, Bruce Momjian wrote: > Jesper Krogh wrote: > >> On 2010-05-03 23:09, Bruce Momjian wrote: >> >>> Robert Haas wrote: >>> >>> >>>> On Sun, May 2, 2010 at 3:45 PM, Dimitri Fontaine<dfontaine(a)hi-media.com> wrote: >>>> >>>> >>>>> Now you tell me how awful this idea really is :) >>>>> >>>>> >>>> I'm not sure I can count that high. :-) >>>> >>>> >>> While I can't improve on Robert's reply, I can supply a PDF about how >>> pg_migrator works: >>> >>> http://momjian.us/main/presentations/technical.html#pg_migrator >>> >>> >>> >> There is a huge amount of users to whom pg_migrator is "at least" >> a big a feature as HS+SR is. >> >> Last dump/restore was a 24 hours process in one of our installations. >> I think it was due to in-efficiency in handling BYTEA types in the >> process (but not sure). >> >> But I'm one of the few guys who seem to have an infinite amount of >> time for reading on mailing lists, but without my knowledge from >> reading this list I would never have run pg_migrator on my production >> data if I had to pick it from pg_foundry. >> > So, did you use "copy" or "link" mode, and how fast was the pg_migrator > upgrade? > > I did go the painful way (dump+restore) at that point in time. It was an 8.1 - 8.3 migration. Since then data has grown and the dump restore is even less favorable on the 8.3 -> 9.0 migration. So in general the pg_migrator way seems to be the only way to aviod the slony way which is orders of magnitude more complicated. Q: I read you pdf, why isn't statistics copied over? It seems to be the last part missing from doing an upgrade in a few minutes. Jesper -- Jesper -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |