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
g...@2ndquadrant.com www.2ndQuadrant.us
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
