Thread: 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!
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 #
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.