Re: State of Beta 2

From: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>, Manfred Koizar <mkoi-pg(at)aon(dot)at>, Lamar Owen <lowen(at)pari(dot)edu>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Dennis Gearon <gearond(at)fireserve(dot)net>, Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net>, PgSQL General ML <pgsql-general(at)postgresql(dot)org>
Subject: Re: State of Beta 2
Date: 2003-09-20 15:57:18
Message-ID: 20030920125442.I6867@ganymede.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sat, 20 Sep 2003, Tom Lane wrote:

> "Marc G. Fournier" <scrappy(at)postgresql(dot)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?

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Joshua D. Drake 2003-09-20 16:01:58 Re: State of Beta 2
Previous Message Tom Lane 2003-09-20 15:51:18 Re: State of Beta 2