Re: 7.1 Release Date

From: teg(at)redhat(dot)com (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=)
To: The Hermit Hacker <scrappy(at)hub(dot)org>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: 7.1 Release Date
Date: 2000-08-29 14:47:45
Message-ID: xuyr978ktta.fsf@hoser.devel.redhat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

The Hermit Hacker <scrappy(at)hub(dot)org> writes:

> On 29 Aug 2000, Trond Eivind [iso-8859-1] Glomsr d wrote:
>
> > The Hermit Hacker <scrappy(at)hub(dot)org> writes:
> >
> > > On 29 Aug 2000, Trond Eivind [iso-8859-1] Glomsr d wrote:
> > >
> > > > The Hermit Hacker <scrappy(at)hub(dot)org> writes:
> > > >
> > > > > On Mon, 28 Aug 2000, Miguel Omar Carvajal wrote:
> > > > >
> > > > > > Hi there,
> > > > > > When will Postgresql 7.1 be released?
> > > > >
> > > > > right now, we're looking at October-ish for going beta, so most likely
> > > > > November-ish for a release ...
> > > >
> > > > Will there be a clean upgrade path this time, or
> > > > yet another dump-initdb-restore procedure?
> > >
> > > IMHO, upgrading a database server is like upgrading an operating system
> > > ... you scheduale downtime, back it all up and upgrade ...
> >
> > The problem is, this doesn't play that well with upgrading the
> > database when upgrading the OS, like in most Linux distributions.
>
> why not? pg_dump;pkrm old;pkadd new;load ... no?

Because the system is down during this upgrade - the database isn't
running. Also, automated dump might lead to data loss if space becomes
an issue.

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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message The Hermit Hacker 2000-08-29 14:52:16 Re: 7.1 Release Date
Previous Message The Hermit Hacker 2000-08-29 14:43:28 Re: 7.1 Release Date