Re: version upgrade

On Aug 31, 2004, at 11:35 PM, Jan Wieck wrote:

> 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.
>
>

What, you don't like living out on the edge? :)

Doing an upgrade via replication is a great way to do it, if you have
the resources available to do so, no argument there.

> 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 ...

In many cases the mere idea of doing an upgrade proves to be difficult,
before you even get to what upgrade procedure to use or whether you
need hardware or not. Add in either of those two issues and people
start to quiver and shake.

>>>
>>> ----
>>> 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
> #
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html
>
--------------------

Andrew Rawnsley
President
The Ravensfield Digital Resource Group, Ltd.
(740) 587-0114
www.ravensfield.com