Thread: upgrade to 8.2.? or implement Slony, which first?
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.? ? -- Until later, Geoffrey Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. - Benjamin Franklin
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: > 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.? ? >
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
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: > 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.? ? >
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).