Re: version upgrade

On 8/31/2004 9:38 PM, Andrew Rawnsley wrote:

> On Aug 31, 2004, at 6:23 PM, Marc G. Fournier wrote:
>
>> On Tue, 31 Aug 2004, Josh Berkus wrote:
>>
>>> Andrew,
>>>
>>>> If I were loony enough to want to make an attempt at a version
>>>> updater
>>>> (i.e. migrate a
>>>> 7.4 database to 8.0 without an initdb), any suggestions on where to
>>>> poke first? Does a
>>>> catalog/list of system catalog changes exist anywhere? Any really
>>>> gross
>>>> problems immediately
>>>> present themselves? Is dusting off pg_upgrade a good place to start,
>>>> or
>>>> is that a dead end?
>>>
>>> Join the Slony project? Seriously, this is one of the uses of
>>> slony. All
>>> you'd need would be a script that would:
>>>
>
> I thought of this quite a bit when I was working over eRServer a while
> back.
>
> Its _better_ than a dump and restore, since you can keep the master up
> while the
> 'upgrade' is happening. But Mark is right - it can be quite
> problematic from an equivalent
> resource point of view. An in-place system (even a faux setup like
> pg_upgrade) would be
> easier to deal with in many situations.

There is something that you will not (or only under severe risk) get
with an in-place upgrade system. The ability to downgrade back in the
case, your QA missed a few gotchas. The application might not instantly
eat the data, but it might start to sputter and hobble here and there.

With the Slony system, you not only switch over to the new version. But
you keep the old system as a slave. That means that if you discover 4
hours after the upgrade that the new version bails out with errors on a
lot of queries from the application, you have the chance to switch back
to the old version and have lost no single committed transaction.

Jan

>
> In the end, using a replication system OR a working pg_upgrade is still
> a pretty creaky
> workaround. Having to do either tends to lob about 15 pounds of nails
> into the gears when
> trying to develop a business case about upgrading (Doesn't necessarily
> stop it dead, but
> does get everyone's attention...). The day when a dump/restore is not
> necessary is
> the day all of us are hoping for.
>
>
>>> 1) Install PG 8.0 to an alternate directory;
>>> 2) Start 8.0;
>>> 3) install Slony on both instances (the 7.4 and the 8.0);
>>> 4) make 7.4 the "master" and start replicating
>>> 5) when 8.0 is caught up, stop 7.4 and promote it to Master
>>> 6) turn off Slony.
>>
>> Slony is not an upgrade utility, and falls short in one big case ..
>> literally .. a very large database with limited cash resources to
>> duplicate it (as far as hardware is concerned). In small shops, or
>> those with 'free budget', Slony is perfect ... but if you are in an
>> organization where getting money is like pulling teeth, picking up a
>> new server "just to do an upgrade" can prove to be difficult ...
>>
>> ----
>> Marc G. Fournier Hub.Org Networking Services
>> (http://www.hub.org)
>> Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ:
>> 7615664
>>
>> ---------------------------(end of
>> broadcast)---------------------------
>> TIP 2: you can get off all lists at once with the unregister command
>> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
>>
> --------------------
>
> Andrew Rawnsley
> President
> The Ravensfield Digital Resource Group, Ltd.
> (740) 587-0114
> www.ravensfield.com
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #