Re: minimizing downtime when upgrading

From: Kenneth Downs <ken(at)secdat(dot)com>
To: Richard Huxton <dev(at)archonet(dot)com>
Cc: snacktime <snacktime(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: minimizing downtime when upgrading
Date: 2006-06-21 12:10:20
Message-ID: 4499372C.9060408@secdat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 Content-Type Size
ken.vcf text/x-vcard 186 bytes

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Martijn van Oosterhout 2006-06-21 12:16:48 Re: merge result sets
Previous Message simon 2006-06-21 12:08:29 Re: merge result sets