Re: Upgrade issue (again). - Mailing list pgsql-hackers

Best way to upgrade might bee to do something as simple as get the
master to master replication working.

Old version on one box, new version on another.  Fire up for
replication -- done automatically -- with both boxes acting as
masters.  Change all the code to use the new server (or new database
on same server), then remove the old one from the queue and turn off
replication.

0 down time, no data migration issues (handled internally by postgres
replication), etc.  Worst part is you'll use double the disk space for
the period of time with 2 masters, and the system will run slower but
atleast it's up.

This is long term future though.  Need master to master replication
first as both servers have to be able to update the other with the new
information while the code that uses it is being changed around.  It
also means that replication will need to be version independent.

Of course, I'm not the one doing this but it sure seems like the
easiest way to go about it since most of the features involved are on
the drawing board already.

--
Rod Taylor

----- Original Message -----
From: "Lamar Owen" <lamar.owen@wgcr.org>
To: "The Hermit Hacker" <scrappy@hub.org>
Cc: <pgsql-hackers@postgresql.org>
Sent: Thursday, May 17, 2001 12:24 PM
Subject: Re: [HACKERS] Upgrade issue (again).


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wednesday 16 May 2001 19:05, The Hermit Hacker wrote:
> > On Wed, 16 May 2001, Lamar Owen wrote:
> > > I am loathe to even bring this up, but with two messages today
about it,
> > > I am going to be short and sweet:
>
> > > We don't have a reasonable upgrade path.  ASCII dump->install
> > > new->initdb->restore is not a reasonable upgrade.  Furthermore,
the
> > > dump/restore cycle is a
> > > pain in the neck when tables get larger than a few hundred
megabytes.
>
> > Personally ... I just upgraded 13 gig worth of databases using
> > dump/restore, didn't have to end a single file, in less then
1.5hrs from
> > start to finish ... *shrug*
>
> And 1.5 hours of downtime wasn't a problem? *raised eyebrow* :-)  Or
did you
> migrate to a different box running the new version?  Or were you
running more
> than one version on the one box?  Some don't have that choice as
easy, nor
> are they as experienced as you and I.  Nor do they desire that much
downtime.
>
> My vision of an ideal upgrade:
> Stop old version postmaster.
> Install new verison.
> Start new version postmaster.
> New version migrates in place while being able to give access to the
old data
> with the only downtime being stopping the old postmaster and
starting the new.
>
> This is hard.  And, as Tom so well put it: it's a lot of boring work
to get
> it to work right. But, IMHO, this is one of the most gifted and
talented set
> of hackers in any open source project -- surely we could find both a
concept
> and implementation of a way to actually do the inplace seamless
upgrade,
> couldn't we?
> - --
> Lamar Owen
> WGCR Internet Radio
> 1 Peter 4:11
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.4 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
>
> iD8DBQE7A/sx5kGGI8vV9eERApiwAKDRzYZSmwpcwlsRcexuGovNA77uNACeLIOS
> g2O3Q0KP4+ODIuqjjvzu3gY=
> =WRxi
> -----END PGP SIGNATURE-----
>
> ---------------------------(end of
broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>