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