need for in-place upgrades (was Re: State of Beta 2) - Mailing list 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.l.johnson@cox.net
Jefferson, LA USA

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