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: Bruce Momjian on 3 May 2010 17:27 Greg Smith wrote: > Bruce Momjian wrote: > > As a summary, let me list the migrations pg_migrator supports: > > 8.3 -> 8.4 > > 8.4 -> 9.0 > > 8.3 -> 9.0 > > Surprisingly, it is 8.3 -> 8.4 that has the most restrictions because it > > doesn't have access to the features we added in Postgres 9.0. > > Tom is right that the code could be cleaned up if we removed 8.3 -> 8.4, > > but more importantly the documentation would be clearer. > > > > I think it's extremely valuable that either 8.3 or 8.4 can be upgraded > to 9.0. But let's face it: in the long run, the number of people who > are going to use pg_migrator for a 8.3->8.4 migration, but that's > haven't already done so, is a small user base. The feature set > improvement in 8.4 had a lot of great stuff, but few that were > compelling from a "now I can do something completely impossible before!" > standpoint. As was noted recently during the "Native DB replication for > PG" discussion over on pgsql-general last week, there are plenty of > people happily running a stable 8.3 who just ignore 8.4 altogether for > that reason. > > The replication features in 9.0 are compelling in that way though, and I > expect to see plenty of upgrades to that version from both 8.3 and 8.4 > installs. If that works fine right now, I would prefer to see that > documented as a special case two-versions at once situation that people > shouldn't necessarily expect in the future, but certainly valuable to > keep going if the maintenance burden isn't so bad. Until we have some kind of "delete the incompatibile format" step in major releases, my bet is that pg_migrator will support many previous major versions, or not work at all. It is hard to see why it would work for some major versions and not others given our current code. > 2) Deprecate the pg_migrator hosted on pg_foundry as only being > recommended for limited 8.3->8.4 upgrades. Essentially stop active > development on the version there, and focus on the one in contrib/ > instead. People who want an improved 8.3->8.4 tool can always contract > with someone to backport fixes needed for their particular use case. I > think we're past the point where the community at large (meaning: > mainly Bruce right now) should be expected to do that, now that 9.0 is > coming out, so long as 8.3 to 9.0 conversions are available too. I > can't imagine suggesting to anyone that they upgrade in-place from 8.3 > to 8.4 right now. Everybody I talk to who isn't already on 8.4 is > delaying upgrades in anticipation of 9.0 later this year or early next. Assuming pg_migrator moves to /contrib, I don't plan on doing much to improve the pgfoundry version unless people find specific bugs. I have not released a 9.0-compatible version there for that reason. -- 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: Alvaro Herrera on 5 May 2010 14:39 So what was the conclusion here? Is pg_migrator going to be in contrib for beta2 or 3, after cleaning it up? -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- 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 5 May 2010 14:55 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. Just my 0.25� 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
From: Bruce Momjian on 5 May 2010 19:44 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.) -- 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: Bruce Momjian on 5 May 2010 19:45
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? -- 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 |