Re: State of Beta 2
От | Marc G. Fournier |
---|---|
Тема | Re: State of Beta 2 |
Дата | |
Msg-id | 20030920125442.I6867@ganymede.hub.org обсуждение исходный текст |
Ответ на | Re: State of Beta 2 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: State of Beta 2
|
Список | pgsql-general |
On Sat, 20 Sep 2003, Tom Lane wrote: > "Marc G. Fournier" <scrappy@postgresql.org> writes: > > On Fri, 19 Sep 2003, Tom Lane wrote: > >> I think we could definitely adopt a policy of "on-disk changes not > >> oftener than every X releases" if we had a working pg_upgrade, > > > 'K, but let's put the horse in front of the cart ... adopt the policy so > > that the work on a working pg_upgrade has a chance of succeeding ... if we > > said no on disk changes for, let's say, the next release, then that would > > provide an incentive (I think!) for someone(s) to pick up the ball and > > No can do, unless your intent is to force people to work on pg_upgrade > and nothing else (a position I for one would ignore ;-)). With such a > policy and no pg_upgrade we'd be unable to apply any catalog changes at > all, which would pretty much mean that 7.5 would look exactly like 7.4. No, I'm not suggesting no catalog changes ... wait, I might be wording this wrong ... there are two changes that right now requires a dump/reload, changes to the catalogs and changes to the data structures, no? Or are these effectively inter-related? If they aren't inter-related, what I'm proposing is to hold off on any data structure changes, but still make catalog changes ... *if*, between v7.4 and v7.5, nobody can bring pg_upgrade up to speed to be able to handle the catalog changes without a dump/reload, then v7.5 will require one ... but, at least it would give a single 'moving target' for the pg_upgrade development to work on, instead of two ... Make better sense?
В списке pgsql-general по дате отправления: