Thread: Product Roadmap question and request for recommendation
What would you do in this situation?
We are currently at PG 8.1 and are in the process of upgrading to 8.3.6. I read on your development roadmap page that 8.4 is slated for release in Q1 of this year, possibly on the 31st of March:
“The next release of PostgreSQL is planned to be the 8.4 release. A tentative schedule for this version has a release in the first quarter of 2009.”
I have also read in the postings that the framework for in-place upgrades is being added to 8.4, so the actual upgrade to the forthcoming 8.5 can be done as in-place (without dump/restore), but there won’t be a way to do an in-place upgrade from any 8.3.x version directly to 8.5.
Upgrading some of our larger databases is rather painful and is a several day effort (staging historical data over time so the actual cutover can realistically be done in a weekend). Right now 8.1 is working well for us, is extremely stable, and provides all of the functionality we need to support our applications. Given this, it sounds to me like it makes sense to wait a bit longer (2nd half of this year) for a 8.4.x version do to the dump/restore against for the last time so we can then, in the future, do in-place upgrades from 8.5 onward.
Any comments you can make on this suggestion would be very much appreciated.
We are currently at PG 8.1 and are in the process of upgrading to 8.3.6. I read on your development roadmap page that 8.4 is slated for release in Q1 of this year, possibly on the 31st of March:
“The next release of PostgreSQL is planned to be the 8.4 release. A tentative schedule for this version has a release in the first quarter of 2009.”
I have also read in the postings that the framework for in-place upgrades is being added to 8.4, so the actual upgrade to the forthcoming 8.5 can be done as in-place (without dump/restore), but there won’t be a way to do an in-place upgrade from any 8.3.x version directly to 8.5.
Upgrading some of our larger databases is rather painful and is a several day effort (staging historical data over time so the actual cutover can realistically be done in a weekend). Right now 8.1 is working well for us, is extremely stable, and provides all of the functionality we need to support our applications. Given this, it sounds to me like it makes sense to wait a bit longer (2nd half of this year) for a 8.4.x version do to the dump/restore against for the last time so we can then, in the future, do in-place upgrades from 8.5 onward.
Any comments you can make on this suggestion would be very much appreciated.
don't fix if it ain't broken ;)
no really, if the system is capable of working nearly flawlessly till 8.4 is baked, then it is sound to wait till then, especially when upgrading to a newer version is a *painful* as in time consuming task. i am assuming downgrading (just incase things don't workout that easily) will be equally painful.
rgds,
dotyet.
no really, if the system is capable of working nearly flawlessly till 8.4 is baked, then it is sound to wait till then, especially when upgrading to a newer version is a *painful* as in time consuming task. i am assuming downgrading (just incase things don't workout that easily) will be equally painful.
rgds,
dotyet.
On Mon, Feb 23, 2009 at 1:09 PM, Keaton Adams <kadams@mxlogic.com> wrote:
What would you do in this situation?
We are currently at PG 8.1 and are in the process of upgrading to 8.3.6. I read on your development roadmap page that 8.4 is slated for release in Q1 of this year, possibly on the 31st of March:
"The next release of PostgreSQL is planned to be the 8.4 release. A tentative schedule for this version has a release in the first quarter of 2009."
I have also read in the postings that the framework for in-place upgrades is being added to 8.4, so the actual upgrade to the forthcoming 8.5 can be done as in-place (without dump/restore), but there won't be a way to do an in-place upgrade from any 8.3.x version directly to 8.5.
Upgrading some of our larger databases is rather painful and is a several day effort (staging historical data over time so the actual cutover can realistically be done in a weekend). Right now 8.1 is working well for us, is extremely stable, and provides all of the functionality we need to support our applications. Given this, it sounds to me like it makes sense to wait a bit longer (2nd half of this year) for a 8.4.x version do to the dump/restore against for the last time so we can then, in the future, do in-place upgrades from 8.5 onward.
Any comments you can make on this suggestion would be very much appreciated.
Keaton Adams <kadams@mxlogic.com> writes:
> We are currently at PG 8.1 and are in the process of upgrading to 8.3.6. I read on your development roadmap page
that8.4 is slated for release in Q1 of this year, possibly on the 31st of March:
> "The next release of PostgreSQL is planned to be the 8.4 release. A tentative schedule for this version has a release
inthe first quarter of 2009."
That's out of date --- there is absolutely zero chance of 8.4 being
released in March. This summer, perhaps.
regards, tom lane
OK, well just to make sure I have the latest and greatest information on the proposed in-place upgrade process.
If we go from 8.1 to 8.3.6 now using dump/restore we will need to do another dump/restore to get to 8.4, correct?
And from 8.4 on we will be able to do in-place upgrades?
The idea of being able to do an in-place upgrade from an 8.3 release is off the table?
Thanks again,
Keaton
On 2/23/09 12:03 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
If we go from 8.1 to 8.3.6 now using dump/restore we will need to do another dump/restore to get to 8.4, correct?
And from 8.4 on we will be able to do in-place upgrades?
The idea of being able to do an in-place upgrade from an 8.3 release is off the table?
Thanks again,
Keaton
On 2/23/09 12:03 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
Keaton Adams <kadams@mxlogic.com> writes:
> We are currently at PG 8.1 and are in the process of upgrading to 8.3.6. I read on your development roadmap page that 8.4 is slated for release in Q1 of this year, possibly on the 31st of March:
> "The next release of PostgreSQL is planned to be the 8.4 release. A tentative schedule for this version has a release in the first quarter of 2009."
That's out of date --- there is absolutely zero chance of 8.4 being
released in March. This summer, perhaps.
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> wrote: > Keaton Adams <kadams@mxlogic.com> writes: > > We are currently at PG 8.1 and are in the process of upgrading to 8.3.6. I read on your development roadmap page that8.4 is slated for release in Q1 of this year, possibly on the 31st of March: > > > "The next release of PostgreSQL is planned to be the 8.4 release. A tentative schedule for this version has a releasein the first quarter of 2009." > > That's out of date --- there is absolutely zero chance of 8.4 being > released in March. This summer, perhaps. :-( Andreas -- Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect. (Linus Torvalds) "If I was god, I would recompile penguin with --enable-fly." (unknown) Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889°
On Mon, Feb 23, 2009 at 1:03 PM, Keaton Adams <kadams@mxlogic.com> wrote: > OK, well just to make sure I have the latest and greatest information on the > proposed in-place upgrade process. > > If we go from 8.1 to 8.3.6 now using dump/restore we will need to do another > dump/restore to get to 8.4, correct? Or you can use slony and have a few seconds of downtime during the switchover.
Dot Yet wrote: > don't fix if it ain't broken ;) > > no really, if the system is capable of working nearly flawlessly till 8.4 is > baked, then it is sound to wait till then, especially when upgrading to a > newer version is a *painful* as in time consuming task. i am assuming > downgrading (just incase things don't workout that easily) will be equally > painful. Actually, pg_migratory will allow upgrades from 8.3 to 8.4 so you could upgrade to 8.3 and upgrade to 8.4 rapidly. I am unsure if an upgrade from 8.2 to 8.4 is possible. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +