Re: version upgrade - Mailing list pgsql-hackers

From Marc G. Fournier
Subject Re: version upgrade
Date
Msg-id 20040901122908.F47186@ganymede.hub.org
Whole thread Raw
In response to Re: version upgrade  (Jan Wieck <JanWieck@Yahoo.com>)
List pgsql-hackers
On Wed, 1 Sep 2004, Jan Wieck wrote:

> On 9/1/2004 10:29 AM, Joe Conway wrote:
>
>> Jeff wrote:
>>> 
>>> On Aug 31, 2004, at 6:30 PM, Josh Berkus wrote:
>>>> Huh?    You can replicate onto the same server.    Kicks your performance 
>>>> in
>>>> the teeth but it works fine.   Heck, I did it on my laptop as a demo.
>>> 
>>> Doesn't work If you have say, a 100GB db and only 50GB free space.
>>> Not nearly enough to duplicate. But plenty of breathing room for normal 
>>> operation.
>>> 
>>> Various db's support in place upgrades. and I'm thankful I tried 
>>> Informix's out on a test db first because it simply scribbled over all the 
>>> data instead of upgrading. Support told me that can happen sometimes. 
>>> COOL HUH?
>> 
>> I think that's an incredibly important point, i.e., even if you want to do 
>> an "in place" upgrade, you ought to be testing it out first on a *full* 
>> copy of your production database. IMHO, anything less than a full test is 
>> playing fast-and-loose with your data. This in turn implies that you need 
>> enough space for a full replica anyway, so why not use slony?
>
> Which is another point I was about to ask. How do these people, running 
> those huge and horribly important databases, ever test a single 
> application change? Or any schema changes for that matter. Do they 
> really type "psql -c 'alter table ...' proddb" and believe they are 
> professional users because they know what they are doing?

You are assuming that they ever make changes ... :)

Please note that nobody is slamming Slony as *an* upgrade option ... what 
we are slamming is that everyone seems to be touting it as *the* upgrade 
option ... they seem to be ignoring the fact that nobody everyone *has* 
the resources required to use a replication (any replication) option as an 
upgrade option ...

God, how many ppl are running applications out there that have never had 
an upgrade in 5 years, because the company that first created it is no 
longer in business ... yet the application *still* does exactly what the 
business wants/needs?

Now, granted, that 5 year old application would probably break if its 
database were upgraded ... the point I'm trying to make is that the 
data format, and application, would be the static component ... the 
backend would be the only thing that changes ... *and* ... there have been 
several 'new releases' of PostgreSQL that have required *zero* changes at 
the application level in order to work, just requiring a dump/reload due 
to changes in the database ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: timezone vs _timezone on Windows
Next
From: Hannu Krosing
Date:
Subject: Re: version upgrade