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: Dimitri Fontaine on 2 May 2010 15:45 <crazy hat on --- but do I ever quit it?> Andrew Dunstan <andrew(a)dunslane.net> writes: > We need to be thinking more now about such a contingency. Postgres use in > very large installations is now at such a level that requiring a > pg_dump/pg_restore is really not an option for many users. If pg_migrator is > not always going to work then we need to be addressing that now, or else it > is at best a stop-gap. ISTM some sort of page layout versioning scheme might > be at least part of what we'll need in the medium term. Would it be on the same complexity level to support recovering WALs from previous version? On the code maintenance alone it sounds bad enough, but apart from that? The idea of course would be then to add an Hot-Standby server running next PostgreSQL version and fed from current production server. The base backup would have to either be processed by pg_migrator or we'd have to open the possibility of starting a slave from a pg_dump, which has been talked about already. The change here would be that this initial step would not be done as part of the maintenance window. Now you tell me how awful this idea really is :) Regards, -- dim -- 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: Robert Haas on 3 May 2010 16:12 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. :-) ....Robert -- 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 3 May 2010 16:19 On Mon, 2010-05-03 at 16:12 -0400, 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. :-) You don't have to... NaN Joshua D. Drake > > ...Robert > -- 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: Greg Smith on 3 May 2010 16:17 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. Balancing out development reality with the ideal situation from the perspective of [potential|current] customers that I deal with every day, what I would prefer to see here is: 1) Commit a streamlined pg_migrator that only handles conversions with 9.0 as a target into contrib, and ship it with 9.0. Like Bruce, I had presumed that the discussion about whether that was going to happen would happen in parallel with beta (read: right now), rather than its already being too late to even consider. I think it's completely bizarre from an advocacy standpoint to even consider that you wouldn't ship such a tool with the core database, now that it's been around for long enough to have a positive track record. 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. My main issues with this project continuing to be hosted in pgfoundry are: 1) Perceived lack of confidence and/or legitimacy for it as an in-place upgrade solution, which would be a terrible PR move. When people ask about in-place upgrades and I tell them "there's a tool you can download for that", they look at me in terror and ask if I'm serious that it isn't just included in the core code. The improvement between answering that way and saying "yes, the tool for 8.3 and 8.4 is included with the core distribution", from the perspective of selling people on adopting PostgreSQL, cannot be overstated. 2) Anyone who looks at pgfoundry for more than a few minutes walks away covered with the scent of dead projects. One reason for that is that related to how painful it is to develop there. I don't want to reignite a full anti-pgfoundry discussion here. Suffice it to say that there are many of us who just can't bear working with CVS anymore who have just given up on doing anything useful to projects hosted there. Something that's in core (and therefore included in the git conversion already being published) is much easier to work with and submit patches against. I'm already dumping git clones of the PG repo on every system I do serious work on. If each of those were then capable of generating pg_migrator patches I could submit, I would actually do that each time I use the tool for an upgrade and notice how it could be improved. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg(a)2ndQuadrant.com www.2ndQuadrant.us -- 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 3 May 2010 17:09
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 -- 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 |