Re: minimizing downtime when upgrading - Mailing list pgsql-general

From Kenneth Downs
Subject Re: minimizing downtime when upgrading
Date
Msg-id 4499372C.9060408@secdat.com
Whole thread Raw
In response to Re: minimizing downtime when upgrading  (Richard Huxton <dev@archonet.com>)
Responses Re: minimizing downtime when upgrading  (Martijn van Oosterhout <kleptog@svana.org>)
Re: minimizing downtime when upgrading  (Alban Hertroys <alban@magproductions.nl>)
List pgsql-general
Richard Huxton wrote:

> Kenneth Downs wrote:
>
>> AFAIK it has always been the case that you should expect to have to
>> dump out your databases and reload them for version upgrades.
>>
>> Is anybody over at the dev team considering what an onerous burden
>> this is?  Is anyone considering doing away with it?
>
>
> Far from trivial.

Kind of gets to the heart of things, though, doesn't it.

It's the non-trivial stuff where we look to the machine to help us out.

As a user of PostgreSQL, I benefit from a lot of things.  I gain a total
advantage of "X" units of time/money.  Then its time to upgrade and I
have to give a lot of it back.  The more I use the package, the more
non-trivial is my upgrade, and the more I give back.

Regardless of whether a package is commercial or free, it strikes me as
counter to the very soul of programming to build in a burden that
increases with the user's use of the program, threatening even to tip
the balance altogether away from its use.  This seems to be the very
kind of feature that you want to programmatically control precisely
because it is non-trivial.


> You have changes in on-disk formats and actual functionality between
> major version numbers. For instance - what would you do to deal with
> the recent changes in unicode validation?
>


Attachment

pgsql-general by date:

Previous
From: simon
Date:
Subject: Re: merge result sets
Next
From: Martijn van Oosterhout
Date:
Subject: Re: merge result sets