Skip site navigation (1) Skip section navigation (2)

Re: 7.1 Release Date

From: teg(at)redhat(dot)com (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=)
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: The Hermit Hacker <scrappy(at)hub(dot)org>, pgsql-general(at)postgresql(dot)org
Subject: Re: 7.1 Release Date
Date: 2000-08-29 15:54:15
Message-ID: xuybsyckqqg.fsf@hoser.devel.redhat.com (view raw or flat)
Thread:
Lists: pgsql-general
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> teg(at)redhat(dot)com (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes:
> > Will there be a clean upgrade path this time, or
> > yet another dump-initdb-restore procedure? 
> 
> Still TBD, I think --- right now pg_upgrade would still work, but if
> Vadim finishes WAL there's going to have to be a dump/reload for that.
> 
> Another certain dump/reload in the foreseeable future will come from
> adding tablespace support/changing file naming conventions.
> 
> > Unclean upgrades are one of major disadvantages of postgresql FTTB,
> > IMHO. 
> 
> You can always stick to Postgres 6.5 :-).  There are certain features
> that just cannot be added without redoing the on-disk table format.
> I don't think we will ever want to promise "no more dump/reload";
> if we do, it will mean that Postgres has stopped improving.

Not necesarrily - one could either design a on disk format with room
for expansion or create migration tools to add new fields.

-- 
Trond Eivind Glomsrød
Red Hat, Inc.

In response to

Responses

pgsql-general by date

Next:From: Ange Michel POZZODate: 2000-08-29 16:11:24
Subject: Re: Re: [GENERAL] cannot vacuum a database !
Previous:From: Alfred PerlsteinDate: 2000-08-29 15:50:41
Subject: Re: Ignore when using COPY FROM

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group