Re: Resurrecting pg_upgrade

From: "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Resurrecting pg_upgrade
Date: 2003-12-15 03:21:42
Message-ID: 1071458502.6603.3.camel@zedora.zeut.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, 2003-12-14 at 18:02, Tom Lane wrote:
> "Matthew T. O'Connor" <matthew(at)zeut(dot)net> writes:
> > How limiting is the above? Does this mean that pg_upgrade will be
> > rendered invalid if there is an on-disk representation change? Do we
> > think we will make it from 7.4 -> 7.5 without on-disk changes? Do we
> > think at this point most upgrades will be without on-disk changes?
>
> How large N will be in practice remains to be seen, of course, but I'd
> expect something on the order of 4 or 5.

Ok, this is what I was looking for. If we are serious about this, would
it make sense to start a new policy of bumping the major version number
every time an upgrade requires a dump / reload? So PostgreSQL 8.0 would
be the next version with on-disk changes, all the 8.x releases would
have the same on-disk format, and the next time the disk format changes,
then we are on 9.0.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2003-12-15 03:27:41 Re: [PATCHES] fork/exec patch
Previous Message Tom Lane 2003-12-15 03:19:30 Re: Resurrecting pg_upgrade