Re: pg_migrator to /contrib in a later 9.0 beta

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: pg_migrator to /contrib in a later 9.0 beta
Дата
Msg-id 201005032127.o43LR3j22186@momjian.us
обсуждение исходный текст
Ответ на Re: pg_migrator to /contrib in a later 9.0 beta  (Greg Smith <greg@2ndquadrant.com>)
Список pgsql-hackers
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@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Further Hot Standby documentation required
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: max_standby_delay considered harmful