upgrade to 8.2.? or implement Slony, which first?

If you don't mind the downtime it would be simpler to upgrade to 8.2 and
then worry about Slony. If you do mind you can use slony to do the
upgrade which needs much less downtime as you switch servers.

Geoffrey wrote:

Joseph S wrote:

If you don't mind the downtime it would be simpler to upgrade to 8.2 and
then worry about Slony. If you do mind you can use slony to do the
upgrade which needs much less downtime as you switch servers.

Interesting point. It's a 24/7 environment, so downtime is unacceptable.

Thanks for the response.

Geoffrey wrote:

We plan to upgrade from our current 7.4.17 Postgresql to 8.2.? in the
near future. We also plan to implement a replication solution, most
likely Slony.

We know that the upgrade to 8.2.? will require some code changes.

Question is, is there a particular order in which we should perform
these changes that would require the least amount of additional work?

That is, would it be more efficient to move to 8.2.? and then
implement our Slony replication, or would there be less effort in
implementing the Slony solution and then upgrading to 8.2.? ?

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

--
Until later, Geoffrey

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
- Benjamin Franklin

On 7/25/07, Geoffrey <lists@serioustechnology.com> wrote:

We plan to upgrade from our current 7.4.17 Postgresql to 8.2.? in the
near future. We also plan to implement a replication solution, most
likely Slony.

We know that the upgrade to 8.2.? will require some code changes.

Question is, is there a particular order in which we should perform
these changes that would require the least amount of additional work?

That is, would it be more efficient to move to 8.2.? and then implement
our Slony replication, or would there be less effort in implementing the
Slony solution and then upgrading to 8.2.? ?

absolutely I would suggest to upgrade to 8.2 unless you already were
on 8.1. note this is not really having anything to do with
slony...it's just that for a 24/7 environment 8.2 is so much easier to
manage with autovacuum, pitr, and better performance all around. If
you were extremely paranoid 8.1 would also be on the table since it's
more mature and is the version provided by most of the enterprise
distros, and there are relatively few killer features on 8.2...IMO,
the most relevant to 24x7 env would be the improved autovac accounting
so you can more easily see what is going on. #2 feature for 24x7 on
8.2 is create index concurrently.

IIRC you can use slony to move the data from the 7.4 to the 8.2
machine and then minimize your downtime (this is one of the nicest
things about slony). In that sense you may want to look at setting up
slony first.

merlin

On Jul 25, 2007, at 6:17 PM, Joseph S wrote:

If you don't mind the downtime it would be simpler to upgrade to
8.2 and then worry about Slony. If you do mind you can use slony
to do the upgrade which needs much less downtime as you switch
servers.

Double-check with the Slony guys, but ISTR that there's an issue
going all the way from 7.4 to 8.2 in a single shot.
--
Jim Nasby jim@nasby.net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

On Jul 27, 2007, at 8:29 PM, Jim Nasby wrote:

Double-check with the Slony guys, but ISTR that there's an issue
going all the way from 7.4 to 8.2 in a single shot.

I don't think that's a slony-specific issue. Moving from 7.4 to 8.0
introduces a fair number of incompatibilities one must address
(mostly quoting and implied type casts as I recall from when we did
the transition).