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. # #================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
