Re: 7.1 Release Date
От | The Hermit Hacker |
---|---|
Тема | Re: 7.1 Release Date |
Дата | |
Msg-id | Pine.BSF.4.21.0008291151090.564-100000@thelab.hub.org обсуждение исходный текст |
Ответ на | Re: 7.1 Release Date (teg@redhat.com (Trond Eivind Glomsrød)) |
Список | pgsql-general |
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 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. woah, I'm confused here ... are you saying that you want to upgrade the database server at the same time, and in conjunction with, upgrading the Operating System?
В списке pgsql-general по дате отправления: