need for in-place upgrades (was Re: State of Beta 2)

From: Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net>
To: PgSQL General ML <pgsql-general(at)postgresql(dot)org>
Subject: need for in-place upgrades (was Re: State of Beta 2)
Date: 2003-09-12 23:54:00
Message-ID: 1063410840.11720.14.camel@haggis
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, 2003-09-12 at 17:48, Joshua D. Drake wrote:
> Hello,
>
> The initdb is not always a bad thing. In reality the idea of just
> being able to "upgrade" is not a good thing. Just think about the
> differences between 7.2.3 and 7.3.x... The most annoying (although
> appropriate) one being that integers can no longer be ''.

But that's just not going to cut it if PostgreSQL wants to be
a serious "player" in the enterprise space, where 24x7 systems
are common, and you just don't *get* 12/18/24/whatever hours to
dump/restore a 200GB database.

For example, there are some rather large companies whose fac-
tories are run 24x365 on rather old versions of VAX/VMS and
Rdb/VMS, because the DBAs can't even get the 3 hours to do
in-place upgrades to Rdb, much less the time the SysAdmin needs
to upgrade VAX/VMS to VAX/OpenVMS.

In our case, we have systems that have multiple 300+GB databases
(working in concert as one big system), and dumping all of them,
then restoring (which includes creating indexes on tables with
row-counts in the low 9 digits, and one which has gone as high
as 2+ billion records) is just totally out of the question.

> If we provide the ability to do a wholesale upgrade many things would
> just break. Heck even the connection protocol is different for 7.4.

But what does a *closed* database care about changed communications
protocols? When you reopen the database after an upgrade the
postmaster and client libs start yakking away in a slightly diff-
erent language, but so what?

> Dennis Gearon wrote:
>
> > Ron Johnson wrote:
> >
> >> On Fri, 2003-09-12 at 10:50, Andrew Rawnsley wrote:
> >>
> >>
> >>> Small soapbox moment here...
> >>>
> >>> ANYTHING that can be done to eliminate having to do an initdb on
> >>> version changes would make a lot of people do cartwheels. 'Do a
> >>> dump/reload' sometimes comes across a bit casually on the lists (my
> >>> apologies if it isn't meant to be), but it can be be incredibly
> >>> onerous to do on a large production system. That's probably why you
> >>> run across people running stupid-old versions.
> >>>
> >>
> >>
> >> And this will become even more of an issue as it's PG's popularity
> >> grows with large and 24x7 databases.
> >>
> >>
> > He is right, it might be a good idea to head this problem 'off at the
> > pass'. I am usually pretty good at predicting technilogical trends.
> > I've made some money at it. And I predict that Postgres will eclipse
> > MySQL and be in the top 5 of all databases deployed. But it does have
> > some achilles tendon's.

--
-----------------------------------------------------------------
Ron Johnson, Jr. ron(dot)l(dot)johnson(at)cox(dot)net
Jefferson, LA USA

"The UN couldn't break up a cookie fight in a Brownie meeting."
Larry Miller

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Stephan Szabo 2003-09-13 02:14:09 Re: difference when using 'distinct on'
Previous Message Joshua D. Drake 2003-09-12 22:48:48 Re: State of Beta 2