Re: 7.1 Release Date
От | teg@redhat.com (Trond Eivind Glomsrød) |
---|---|
Тема | Re: 7.1 Release Date |
Дата | |
Msg-id | xuyr978ktta.fsf@hoser.devel.redhat.com обсуждение исходный текст |
Ответ на | Re: 7.1 Release Date (The Hermit Hacker <scrappy@hub.org>) |
Ответы |
Re: 7.1 Release Date
|
Список | pgsql-general |
The Hermit Hacker <scrappy@hub.org> writes: > On 29 Aug 2000, Trond Eivind [iso-8859-1] Glomsr d wrote: > > > The Hermit Hacker <scrappy@hub.org> writes: > > > > > On 29 Aug 2000, Trond Eivind [iso-8859-1] Glomsr d wrote: > > > > > > > The Hermit Hacker <scrappy@hub.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.
В списке pgsql-general по дате отправления: