On 9/1/2004 1:51 PM, Serguei A. Mokhov wrote:

> Date: Tue, 31 Aug 2004 23:35:18 -0400
> 
> 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.
> 
> Just asking: how far back in time Slony can "downgrade" or keep the older
> servers in "slavery"? 6.5? I haven't tried it yet, hence, the question.
> 

Slony runs on 7.3.3 and better.


Jan

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

Wed, 01 Sep 2004 13:50:52 -0400
Jan Wieck <JanWieck@Yahoo.com>
Re: version upgrade
Date: Tue, 31 Aug 2004 23:35:18 -0400

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.

Just asking: how far back in time Slony can "downgrade" or keep the older
servers in "slavery"? 6.5? I haven't tried it yet, hence, the question.

-- 
Serguei A. Mokhov            |  /~\    The ASCII
Computer Science Department  |  \ / Ribbon Campaign
Concordia University         |   X    Against HTML
Montreal, Quebec, Canada     |  / \      Email!

Wed, 1 Sep 2004 13:51:10 -0400 (EDT)
"Serguei A. Mokhov" <mokhov@cs.concordia.ca>
version upgrade
On Wed, 2004-09-01 at 13:50, Jan Wieck wrote:
> On 9/1/2004 1:51 PM, Serguei A. Mokhov wrote:
> 
> > Date: Tue, 31 Aug 2004 23:35:18 -0400
> > 
> > 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.
> > 
> > Just asking: how far back in time Slony can "downgrade" or keep the older
> > servers in "slavery"? 6.5? I haven't tried it yet, hence, the question.
> > 
> 
> Slony runs on 7.3.3 and better.

If you're willing to put some time into removing schema references,
Slony will function on 7.2 -- but it's not pretty.



Wed, 01 Sep 2004 15:10:13 -0400
Rod Taylor <pg@rbt.ca>
Re: version upgrade