Re: Considering an upgrade...

From: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>
To: pgsql-general(at)postgresql(dot)org
Cc: Scott Marlowe <smarlowe(at)g2switchworks(dot)com>, Gary Horton <Gary(dot)Horton(at)Sun(dot)COM>
Subject: Re: Considering an upgrade...
Date: 2005-10-12 22:15:36
Message-ID: 200510121815.36522.xzilla@users.sourceforge.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tuesday 11 October 2005 14:59, Scott Marlowe wrote:
> On Tue, 2005-10-11 at 10:50, Gary Horton wrote:
> > I'm needing to convince my boss that we should upgrade from 7.3.4 to
> > 8.x Postgresql. I've already enumerated the upsides, but now we need
> > to consider the risks...I wonder if anyone can mention/summarize any
> > issues, problems, gotchas, etc. that have happened in anyone's upgrade
> > from 7.x to 8.x ... this would be greatly appreciated. For that
> > matter, if there are any benefits people have seen in addition to
> > what's mentioned on postgres website, this would be good info too.
> >
> > We are on a Solaris system (including customers with sol 8, 9, and
> > 10), running 7.3.4. Thanks in advance ... and if you would, please cc
> > me at my email address since I'm not subscribed to this alias.
>
> If you'd like to see if all your data works in 8.0 AND that all your
> updates / inserts / deletes work there too, you can use the trick of
> making a slony replicant running 8.0 under your 7.3 server and seeing if
> everything runs smoothly on the 8.0 server before trying it under the
> real app. This will let you make sure it works in production before
> committing to an update.
>

IIRC Slony wont run on anything < 7.3.6, so you would have to do an in place
upgrade to 7.3.x as appropriate, and then you could set up slony to propogate
to the 8.x system.

Outside of using the slony method the main issues to be aware of are having
enough space to pg_dump out your 7.3 systems and then loading them up into
8.0. I always recommened using the 8.x pg_dump. The advantage to this is
that you can test this entire process a few time to make sure there are no
schema issues or application issues on the new db. Don't forget to time the
process so you can plan your outage accordingly.

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Marc G. Fournier 2005-10-12 22:18:16 Re: [GENERAL] Oracle buys Innobase
Previous Message Brian Mathis 2005-10-12 22:06:44 PG 8.0.4, Centos and 64 bit