Hi all!
We are currently running a 7.3.4 backed and planning to upgrade.
However we can't do to much/at all changes in the applications using the db.
So the question is to what version to upgrade :
what is the best release from the 7.3.* ?
would the upgrade to 7.4.* require serious changes in the applications ,
if not what is the
best release of the 7.4.*?
Thanks.

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

On Wed, Dec 15, 2004 at 11:52:35 +0200,
Tsirkin Evgeny <tsurkin@mail.jct.ac.il> wrote:
> Hi all!
> We are currently running a 7.3.4 backed and planning to upgrade.
> However we can't do to much/at all changes in the applications using the db.
> So the question is to what version to upgrade :
> what is the best release from the 7.3.* ?

The one with the highest number in the third position. You can check
the download sites to see what versions are available. If you have to use
something supported by your OS vendor than you may have more limited
options.

> would the upgrade to 7.4.* require serious changes in the applications ,
> if not what is the
> best release of the 7.4.*?

You would have to do a dump and reload to go to the 7.4 series. I don't
think there is too much else that would cause a problem, but you should
read the release notes to double check that there isn't anything that
will cause you problems.

> Thanks.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

On Wed, 2004-12-15 at 03:52, Tsirkin Evgeny wrote:
> Hi all!
> We are currently running a 7.3.4 backed and planning to upgrade.
> However we can't do to much/at all changes in the applications using the db.
> So the question is to what version to upgrade :
> what is the best release from the 7.3.* ?
> would the upgrade to 7.4.* require serious changes in the applications ,
> if not what is the
> best release of the 7.4.*?

The best version of any major release is the latest minor version. As
of this writing, the latest minor version of the 7.3 branch is 7.3.8,
and the latest minor version of the 7.4 branch is 7.4.6.

Upgrades from one minor version to another (i.e. 7.3.4 to 7.3.8) are
usually painless and simple:

-- Always backup ahead of time just in case.
-- Stop the server.
-- Upgrade PostgreSQL.
-- Start server.

No changes to client side apps should be necessary.

For upgrades from one major version to the next, you'll need to:

-- pg_dump all databases in the cluster. (optionally, also backup the
files in the $PGDATA directory)
-- Clean out the $PGDATA directory (keep a copy of your pg_hba.conf and
postgresql.conf for reference)
-- Uninstall old version of PostgreSQL
-- Install new version of PostgreSQL
-- initdb with the proper locale
-- edit your pg_hba.conf and postgresql.conf
-- start database
-- restore from backups.

I'd recommend a test run of the major upgrade procedures you're planning
on doing on a backup machine in case you run into some problems. Use of
a replication engine, like Slony as well as pgpool can allow you to
seamlessly upgrade your installation while it stays online. I'd
practice this too on a backup system before going after the live
servers.

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

On Wed, Dec 15, 2004 at 10:09:32AM -0600, Bruno Wolff III wrote:
>
> You would have to do a dump and reload to go to the 7.4 series.

....and the "If You Are Upgrading" section of the "Installation
Instructions" chapter in the documentation recommends using pg_dumpall
from the version you're upgrading to, due to bug fixes and improvements.

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

2 bits of wisdom:

1. As mentioned below, always try this upgrade on a test/ offline/
sandbox/ development/ testing /etc server first

> -- Clean out the $PGDATA directory (keep a copy of your pg_hba.conf and
> postgresql.conf for reference)

2. A simple 'mv data/ data73/' after pg shutdown keeps your 7.3 DB around
incase something goes terribly wrong (i have had some dumps that would
*not* re-import themselves due to illegal characters). If you need to get
back online asap, just slip the 7.3 rpms back in, and 'mv data73 data'

> I'd recommend a test run of the major upgrade procedures you're planning
> on doing on a backup machine in case you run into some problems. Use of
> a replication engine, like Slony as well as pgpool can allow you to
> seamlessly upgrade your installation while it stays online. I'd
> practice this too on a backup system before going after the live
> servers.

[ \ /
[ >X< Christian Fowler | spider AT viovio.com
[ / \ http://www.viovio.com | http://www.tikipro.org



---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

On Wed, Dec 15, 2004 at 10:20:00AM -0600, Scott Marlowe wrote:
> For upgrades from one major version to the next, you'll need to:
>
> -- pg_dump all databases in the cluster. (optionally, also backup the
> files in the $PGDATA directory)

[&c.]

Or

-- install Slony-I
-- replicate from 7.3.x -> 7.4.y (where x >2)
-- catch up
-- move set

We've had quite a few reports of big successes upgrading this way; it
works well if you have the disk space.


A

--
Andrew Sullivan | ajs@crankycanuck.ca
This work was visionary and imaginative, and goes to show that visionary
and imaginative work need not end up well.
--Dennis Ritchie

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly