Обсуждение: State of support for back PG branches
I had originally been planning to back-port this fix: http://archives.postgresql.org/pgsql-committers/2005-08/msg00213.php as far as 7.2. I've completed the back-port as far as 7.3, but found that 7.2 would be significantly more work because the API of heap_fetch() would need to change from what it was back then, and the patch would therefore have to touch many places that it does not touch in later versions. Given that the bug is so low-probability that it's escaped detection all this time, it doesn't really seem worth the effort (not to mention risk of creating new bugs). This brings up the question of whether we should officially abandon support for 7.2 and/or later branches. I don't think anyone is planning on supporting old branches forever, but when do we stop? I have a corporate need to keep supporting 7.3, at least to the extent of critical bug fixes, because Red Hat is still on the hook to support that version in RHEL3 for awhile longer. I have no such interest in 7.2 (which is one reason I'm not excited about doing the extra work to back-patch the VACUUM/ctid fix). I can definitely see that the community might not want to expend more effort on 7.3, though. I have no idea what the needs of other distributions might be. Thoughts anyone? regards, tom lane
Hi, On Mon, 26 Sep 2005, Tom Lane wrote: <snipped> > This brings up the question of whether we should officially abandon > support for 7.2 and/or later branches. I don't think anyone is planning > on supporting old branches forever, but when do we stop? > > I have a corporate need to keep supporting 7.3, at least to the extent > of critical bug fixes, because Red Hat is still on the hook to support > that version in RHEL3 for awhile longer. I have no such interest in > 7.2 (which is one reason I'm not excited about doing the extra work to > back-patch the VACUUM/ctid fix). I can definitely see that the > community might not want to expend more effort on 7.3, though. I have > no idea what the needs of other distributions might be. Doesn't Red Hat support RHEL 2.1, and so that PostgreSQL 7.1? Anyway, IMHO PGDG should stop supporting 7.2 when 8.1 will be officially released. But at this point, (recalling the vacuum bug) it may "now" be time to abandon supporting 7.2. Also, as the RPM maintainer of PGDG, it is hard to support 7.2 for us, too. Compiling 7.2 on newer platforms becomes a pain... There are some 7.3 users around (I remember some on Slony lists, etc), therefore we should keep supporting it. But maybe we can announce that "7.3 will become unsupported after XXX time" so that people will know before we abandon the support. The best time for not supporting 7.3 might be when 8.2 will be released. However, I believe that 7.4 should live longer, since that's the last of the 7.X branch. Regards, -- Devrim GUNDUZ Kivi Bilişim Teknolojileri - http://www.kivi.com.tr devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org
Devrim GUNDUZ <devrim@gunduz.org> writes:
> There are some 7.3 users around (I remember some on Slony lists, etc),
> therefore we should keep supporting it. But maybe we can announce that
> "7.3 will become unsupported after XXX time" so that people will know
> before we abandon the support. The best time for not supporting 7.3 might
> be when 8.2 will be released. However, I believe that 7.4 should live
> longer, since that's the last of the 7.X branch.
Well, the distinction between the 7.X and 8.X branches is more marketing
than anything else ;-). I just went back through the release notes and
recalled that 7.2 is the first branch we *ever* continued to support
past the initial release of the next major version --- for all the older
branches, the last point release predates initial release of the next
branch. And I think we really only started that policy because we found
some pretty serious data-loss bugs shortly after 7.3 came out (see 7.2.4
release notes), and felt we had to do a 7.2 update.
To my mind the main rationale for continuing to support 7.2 is that it
was the last pre-schema release, and so people whose apps haven't yet
been fixed to cope with schemas will be on their own once we drop it.
While each release has some portability gotchas, I don't think there
have been any quite that big since then. If we drop support for 7.2,
it wouldn't be out of the question for us to drop 7.3 and 7.4 too (at
least not from where I sit ... I'm sure some will differ).
If we want to have some sort of fixed policy for support lifespan, I
would suggest it be like "X amount of time after the release of the
following major version". But X probably has to depend on how big
the compatibility gotchas are in the following version, so we're still
really talking about a judgment call here.
regards, tom lane
Tom Lane wrote: >If we want to have some sort of fixed policy for support lifespan, I >would suggest it be like "X amount of time after the release of the >following major version". But X probably has to depend on how big >the compatibility gotchas are in the following version, so we're still >really talking about a judgment call here. > > > > I'm not sure that that's going to help users much. I should think around 3 years (or some such predictable period) is a reasonable lifetime goal for a piece of software like this, accompanied by some weasel words. Maybe something like this would do: "We will attempt to maintain support of each major version for 3 years after its release, although this will not always be possible. After that time any major support requirement is likely to result in support being ended." cheers andrew
On Mon, 26 Sep 2005, Andrew Dunstan wrote: > > > Tom Lane wrote: > >> If we want to have some sort of fixed policy for support lifespan, I >> would suggest it be like "X amount of time after the release of the >> following major version". But X probably has to depend on how big >> the compatibility gotchas are in the following version, so we're still >> really talking about a judgment call here. >> >> >> > > I'm not sure that that's going to help users much. I should think around > 3 years (or some such predictable period) is a reasonable lifetime goal > for a piece of software like this, accompanied by some weasel words. > Maybe something like this would do: "We will attempt to maintain support > of each major version for 3 years after its release, although this will > not always be possible. After that time any major support requirement is > likely to result in support being ended." This sounds reasonable to me ... I think it is more then most software projects do, isn't it? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
[ Forgot to answer this part ]
Devrim GUNDUZ <devrim@gunduz.org> writes:
> On Mon, 26 Sep 2005, Tom Lane wrote:
>> I have a corporate need to keep supporting 7.3, at least to the extent
>> of critical bug fixes, because Red Hat is still on the hook to support
>> that version in RHEL3 for awhile longer.
> Doesn't Red Hat support RHEL 2.1, and so that PostgreSQL 7.1?
Yeah, but I'm not expecting any help from the community on that ;-).
(In practice it's hard to imagine any support request for which I'd
not tell the user to get off 7.1 anyway...)
7.3 is still reasonably supportable, ie, it's not so full of unfixable
problems. Nonetheless it's not clear that the PG development community
ought to be spending time on it. One way to phrase this discussion is
whether the community still wants to help me support 7.3/RHEL3. If
y'all feel you have better uses of your time, I understand completely.
regards, tom lane
"Marc G. Fournier" <scrappy@postgresql.org> writes:
> On Mon, 26 Sep 2005, Andrew Dunstan wrote:
>> Maybe something like this would do: "We will attempt to maintain support
>> of each major version for 3 years after its release, although this will
>> not always be possible. After that time any major support requirement is
>> likely to result in support being ended."
> This sounds reasonable to me ... I think it is more then most software
> projects do, isn't it?
To translate that into reality: 7.2 (2002-02-04) would be dead already,
and 7.3 (2002-11-27) will be dead around the time we are likely to
release 8.1. Do people feel comfortable with that? It seems to fit
with what I'd like to do right at the moment, which is to release
updates back to 7.3 but not 7.2.
I'd prefer to measure the time from the release of the follow-on
version, so I'd make it "2 years from release of following major
version"; that would give people a clearer idea of the time frame
in which they're expected to update their applications. But I'm not
wedded to that.
regards, tom lane
Tom Lane wrote: >"Marc G. Fournier" <scrappy@postgresql.org> writes: > > >>On Mon, 26 Sep 2005, Andrew Dunstan wrote: >> >> >>>Maybe something like this would do: "We will attempt to maintain support >>>of each major version for 3 years after its release, although this will >>>not always be possible. After that time any major support requirement is >>>likely to result in support being ended." >>> >>> > > > >>This sounds reasonable to me ... I think it is more then most software >>projects do, isn't it? >> >> > >To translate that into reality: 7.2 (2002-02-04) would be dead already, >and 7.3 (2002-11-27) will be dead around the time we are likely to >release 8.1. > It doesn't say we must drop it, it says we can after 3 years (or 1 release + 2 years if you like) without any troubles of conscience. ISTM that we could and possibly should keep supporting it until it appeared some major patch was required that was too much work or too dangerous. Remember, many people don't want to jump onto a release right away - I know of large enterprises that have a policy not to use the .0 version of anything. So a 3 year cycle is more likely to be a 2 1/2 year cycle in reality. Then factor in testing and migration time and the production life in the field between deployment and end of life might be only about 2 years. That's plenty short enough, especially as we still don't have a nice pg_upgrade utility. cheers andrew
On Mon, 26 Sep 2005, Tom Lane wrote: > "Marc G. Fournier" <scrappy@postgresql.org> writes: >> On Mon, 26 Sep 2005, Andrew Dunstan wrote: >>> Maybe something like this would do: "We will attempt to maintain support >>> of each major version for 3 years after its release, although this will >>> not always be possible. After that time any major support requirement is >>> likely to result in support being ended." > >> This sounds reasonable to me ... I think it is more then most software >> projects do, isn't it? > > To translate that into reality: 7.2 (2002-02-04) would be dead already, > and 7.3 (2002-11-27) will be dead around the time we are likely to > release 8.1. Do people feel comfortable with that? It seems to fit > with what I'd like to do right at the moment, which is to release > updates back to 7.3 but not 7.2. IMHO ... after 3 years of running on a version, if someone hasn't hit some of the bugs that we're back-patching for, the either aren't going to, or should have that as an encouragement to upgrade ... in most cases, I believe that alot of the ones you've back patched for, its something you've fixed in a "recent release", and ended up going looking for in past releases to make sure they were safe ... no? > I'd prefer to measure the time from the release of the follow-on > version, so I'd make it "2 years from release of following major > version"; that would give people a clearer idea of the time frame > in which they're expected to update their applications. But I'm not > wedded to that. 'k, if you mean 'major version' == x.0 (ie. 7.0.0, 8.0.0), then I think the span of time + 2 years is *way* too long, considering an average of, what, 5 years between major releases ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
"Marc G. Fournier" <scrappy@postgresql.org> writes:
> On Mon, 26 Sep 2005, Tom Lane wrote:
>> I'd prefer to measure the time from the release of the follow-on
>> version, so I'd make it "2 years from release of following major
>> version"; that would give people a clearer idea of the time frame
>> in which they're expected to update their applications. But I'm not
>> wedded to that.
> 'k, if you mean 'major version' == x.0 (ie. 7.0.0, 8.0.0), then I think
> the span of time + 2 years is *way* too long, considering an average of,
> what, 5 years between major releases ...
No, I mean the clock starts to run on 8.0 when we release 8.1. It's
been about a year between major releases lately, so "1 release + 2 years"
is in the same ballpark as "3 years". But I think the former gives
people more clarity about how much time they have to do upgrades.
It's not a big deal either way, probably --- for instance, as of now
7.2 is dead and 7.3 still alive by either rule.
regards, tom lane
>>> This sounds reasonable to me ... I think it is more then most software >>> projects do, isn't it? >> >> >> To translate that into reality: 7.2 (2002-02-04) would be dead already, >> and 7.3 (2002-11-27) will be dead around the time we are likely to >> release 8.1. Do people feel comfortable with that? It seems to fit >> with what I'd like to do right at the moment, which is to release >> updates back to 7.3 but not 7.2. > > I think there should be levels of support. previous major release less than 18 month old (this would cover 7.4): Bug fixes, security fixes previous major release greator than 18 months but not over 3 years: security fixes Over 3 years... your on your own. Although this will be tougher as versions such as 7.4 could easily be running in another 3 years as it is a reasonable stable version without any significant issue (meaning production issue bugs). Also from a commercial perspective the community would be freed up a little to concentrate on delivering the kick ass product, where commercial interests could help keep up with bug fixes, security fixes on older releases etc... Heck that is what RedHat does. Sincerely, Joshua D. Drake -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
"Joshua D. Drake" <jd@commandprompt.com> writes:
> I think there should be levels of support.
There already are, in that only fairly major bugs get backpatched to the
way-back releases. I think that's right --- the older a release is, the
more it means that people still using it value stability over the latest
fixes. The question at hand is when are we willing to pull the plug
completely and declare that even security holes and data-loss risks
won't get fixed.
> Although this will be tougher as versions such as 7.4 could easily be
> running in another 3 years
> as it is a reasonable stable version without any significant issue
> (meaning production issue bugs).
Yeah. The biggest reason we declared 7.1 unsupported is that it has the
unfixable transaction-ID-wraparound problem, and we wanted to encourage
people to stop using 7.1 and before ASAP. 7.2 has some pretty serious
unfixable problems too, such as the lack of error checking associated
with OPAQUE-using functions (ye olde "select cash_out(2)" crash).
7.3 is the oldest version that I think is actually supportable, in that
there are no known, unfixable security or data-loss risks.
So another way we might approach this is that it's time to kill 7.2
because we want to encourage people to get off it sooner not later, but
7.3 and later still have an indefinite support lifespan ahead of them.
In that mindset, we'd only pull the plug on a version when an
identifiable reason to kill it emerges. I'd still not commit to an
infinite lifespan --- but we might be willing to support solid versions
for as long as, say, five years.
Or, as you say, we could take the viewpoint that there are commercial
companies willing to take on the burden of supporting back releases, and
the development community ought not spend its limited resources on doing
that. I'm hesitant to push that idea very hard myself, because it would
look too much like I'm pushing the interests of my employer Red Hat
... but certainly there's a reasonable case to be made there.
regards, tom lane
On Mon, Sep 26, 2005 at 05:57:08PM -0400, Tom Lane wrote: > I had originally been planning to back-port this fix: > http://archives.postgresql.org/pgsql-committers/2005-08/msg00213.php > as far as 7.2. I've completed the back-port as far as 7.3, but > found that 7.2 would be significantly more work because the API of > heap_fetch() would need to change from what it was back then, and > the patch would therefore have to touch many places that it does not > touch in later versions. Given that the bug is so low-probability > that it's escaped detection all this time, it doesn't really seem > worth the effort (not to mention risk of creating new bugs). > > This brings up the question of whether we should officially abandon > support for 7.2 and/or later branches. I don't think anyone is > planning on supporting old branches forever, but when do we stop? > > I have a corporate need to keep supporting 7.3, at least to the > extent of critical bug fixes, because Red Hat is still on the hook > to support that version in RHEL3 for awhile longer. I have no such > interest in 7.2 (which is one reason I'm not excited about doing the > extra work to back-patch the VACUUM/ctid fix). I can definitely see > that the community might not want to expend more effort on 7.3, > though. I have no idea what the needs of other distributions might > be. > > Thoughts anyone? Expiry dates are good. Although there are people who don't read anything, enough people will read release notes that have a definite date attached, as in: PostgreSQL 8.1 Released: November 30, 2005 Community support ends: November 30, 2008 This could be softened a bit in a sentence or two below :) Cheers, D -- David Fetter david@fetter.org http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote!
> The question at hand is when are we willing to pull the plug >completely and declare that even security holes and data-loss risks >won't get fixed. > > It is definitely a sensitive issue because we (my community hat on) want to make sure and not alienate people because we won't support a version for very long. However most major projects do this to a degree. RedHat does not release fixes for 7.3 anymore for example. Although the fedora-legacy project does. I don't know if it is affiliated with RedHat like Fedora is though. >7.3 is the oldest version that I think is actually supportable, in that >there are no known, unfixable security or data-loss risks. > > I would think that 7.3 would be security fixes and data loss fixes only. It will be 3 years old in two months. In OSS terms that is quite a long time. This isn't like Windows where you see a release every 5 years. From a commercial perspective, I do have quite a few customers still on 7.3. Frankly I won't be able to get many of them to upgrade *until* the community deprecates 7.3. >So another way we might approach this is that it's time to kill 7.2 >because we want to encourage people to get off it sooner not later, but >7.3 and later still have an indefinite support lifespan ahead of them. > > Well from a community perspective that is definitely a very nice way to approach. Possibly a sub community or pgFoundry project --- postgresql-legacy? >In that mindset, we'd only pull the plug on a version when an >identifiable reason to kill it emerges. I'd still not commit to an >infinite lifespan --- but we might be willing to support solid versions >for as long as, say, five years. > > Five years is an awful long time in our community. We would in theory still be supporting 7.1. 7.1 was a great distro in comparison to 7.0. Although it did have the XID issue. >Or, as you say, we could take the viewpoint that there are commercial >companies willing to take on the burden of supporting back releases, and >the development community ought not spend its limited resources on doing >that. I'm hesitant to push that idea very hard myself, because it would >look too much like I'm pushing the interests of my employer Red Hat >... but certainly there's a reasonable case to be made there. > > Well one way to look at it, is that by doing so the community is enabling a commercial opportunity which in turn, could (and hopefully would) encourage said commercial entities to donate more resources to the project. Look at how much RedHat gives to Gnome, or Novell to mono. I know it is not the community responsibility to ensure a commercial opportunity but it can't hurt either. Sincerely, Joshua D. Drake > regards, tom lane > > -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
Tom, > Or, as you say, we could take the viewpoint that there are commercial > companies willing to take on the burden of supporting back releases, and > the development community ought not spend its limited resources on doing > that. I'm hesitant to push that idea very hard myself, because it would > look too much like I'm pushing the interests of my employer Red Hat > ... but certainly there's a reasonable case to be made there. Well, I think you know my opinion on this. Since there *are* commercial companies available, I think we should use them to reduce back-patching effort. I suggest that our policy should be: the community will patch two old releases, and beyond that if it's convenient, but no promises. In other words, when 8.1 comes out we'd be telling 7.3 users "We'll be patching this only where we can apply 7.4 patches. Otherwise, better get a support contract." Of course, a lot of this is up to individual initiative; if someone fixes a patch so it applies back to 7.2, there's no reason not to make it available. However, there's no reason *you* should make it a priority. --Josh
On Mon, Sep 26, 2005 at 09:27:28PM -0400, Andrew Dunstan wrote:
> Tom Lane wrote:
>
> >"Marc G. Fournier" <scrappy@postgresql.org> writes:
> >
> >
> >>On Mon, 26 Sep 2005, Andrew Dunstan wrote:
> >>
> >>
> >>>Maybe something like this would do: "We will attempt to maintain support
> >>>of each major version for 3 years after its release, although this will
> >>>not always be possible. After that time any major support requirement is
> >>>likely to result in support being ended."
> >>>
> >>>
> >
> >
> >
> >>This sounds reasonable to me ... I think it is more then most software
> >>projects do, isn't it?
> >>
> >>
> >
> >To translate that into reality: 7.2 (2002-02-04) would be dead already,
> >and 7.3 (2002-11-27) will be dead around the time we are likely to
> >release 8.1.
> >
>
> It doesn't say we must drop it, it says we can after 3 years (or 1
> release + 2 years if you like) without any troubles of conscience. ISTM
> that we could and possibly should keep supporting it until it appeared
> some major patch was required that was too much work or too dangerous.
>
> Remember, many people don't want to jump onto a release right away - I
> know of large enterprises that have a policy not to use the .0 version
> of anything. So a 3 year cycle is more likely to be a 2 1/2 year cycle
> in reality. Then factor in testing and migration time and the production
> life in the field between deployment and end of life might be only about
> 2 years. That's plenty short enough, especially as we still don't have a
> nice pg_upgrade utility.
We started our upgrade from 7.2 to 7.4 about 20 months ago and finished it
about 10 months ago, skipping 7.3 entirely.
We've only just today hit our first problem in 7.4, and it's fixed by
upgrading to 7.4.current, rather than the 7.4.something we originally
upgraded to from 7.2.something.
We'll be skipping 8.0 completely and the next step will probably be to
8.1.something (or possibly 8.2.something, depending on how bizgres
looks in 3 months time). We'd probably consider upgrading our
customers more often, but a dump and restore is extremely painful.
Just a view from the pg-based-enterprise-application world.
A nice pg_upgrade utility would make a big difference. Clearly an
in-place upgrade is possible, but maintaining is hard. There are two
broad ways of running a pg_upgrade project - one that is entirely
independent of the main codebase and one that puts requirements on the
main codebase developers ("if you change $foo you provide code to
translate old $foo to new $foo"). Any feel for the relative difficulty
of the two approaches? And how much push-back there'd be on the latter?
Cheers, Steve
>A nice pg_upgrade utility would make a big difference. Clearly an
>in-place upgrade is possible, but maintaining is hard. There are two
>broad ways of running a pg_upgrade project - one that is entirely
>independent of the main codebase and one that puts requirements on the
>main codebase developers ("if you change $foo you provide code to
>translate old $foo to new $foo"). Any feel for the relative difficulty
>of the two approaches? And how much push-back there'd be on the latter?
>
>
You can do in place upgrades with Slony-I and Mammoth Replicator.
Sincerely,
Joshua D. Drake
>Cheers,
> Steve
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 6: explain analyze is your friend
>
>
--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
Steve Atkins <steve@blighty.com> writes:
> We'll be skipping 8.0 completely and the next step will probably be to
> 8.1.something (or possibly 8.2.something, depending on how bizgres
> looks in 3 months time).
[ raised eyebrow... ] Has bizgres obtained a crystal ball from
somewhere? There is *no* way anyone could provide you anything that
has any legitimate claim on the name "PG 8.2" three months from now.
regards, tom lane
>[ raised eyebrow... ] Has bizgres obtained a crystal ball from >somewhere? There is *no* way anyone could provide you anything that >has any legitimate claim on the name "PG 8.2" three months from now. > > I **think** what he meant was that depending on what Bizgres has done in the next three months they may not run 8.1 but run Bizgres instead. Sincerely, Joshua D. Drake > regards, tom lane > >---------------------------(end of broadcast)--------------------------- >TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq > > -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
Tom Lane wrote: > To my mind the main rationale for continuing to support 7.2 is that it > was the last pre-schema release, and so people whose apps haven't yet > been fixed to cope with schemas will be on their own once we drop it. > While each release has some portability gotchas, I don't think there > have been any quite that big since then. If we drop support for 7.2, > it wouldn't be out of the question for us to drop 7.3 and 7.4 too (at > least not from where I sit ... I'm sure some will differ). Yes. For one of our application that makes massive use of triggers the transition from 7.2 to 7.3 was less painful than 7.4 to 8.0. Many of the triggers were written with the assumption that foreign key checks were effectively delayed until the end of the calling statement. Just another opinion. Nevertheless if it's feasible to support 7.4 for a while, I would recommend it. Also from a marketing statepoint -- having back branches supported for a visible amount of time increases people's confident in PostgreSQL and it's stability. Best Regards, Michael Paesold
On Mon, Sep 26, 2005 at 09:54:46PM -0700, Joshua D. Drake wrote: > >[ raised eyebrow... ] Has bizgres obtained a crystal ball from > >somewhere? There is *no* way anyone could provide you anything that > >has any legitimate claim on the name "PG 8.2" three months from now. > > > > > > I **think** what he meant was that depending on what Bizgres has done in > the next three > months they may not run 8.1 but run Bizgres instead. Partly that, yes. Once 8.1 has stabilized we'll look at 8.1, bizgres as current at that point and the 8.2 crystal ball and decide where the sweet spot is for our needs. The only crystal ball involved is the assumption that if bizgres has Neat Stuff(tm) that would be of widespread use in it's development tree at that point then the odds are good that it, or something functionally equivalent to it, will appear in the 8.2 development tree. If the neat stuff is neat enough we may push off an update from 7.4 and develop using some of that neat stuff, with the plan of deploying either to bizgres or to 8.2. (My best guess right now is that 8.1 will be the right thing to move to,but I'm delaying that decision until next year.) Cheers, Steve
steve@blighty.com (Steve Atkins) writes:
> We started our upgrade from 7.2 to 7.4 about 20 months ago and finished it
> about 10 months ago, skipping 7.3 entirely.
We did similar; there was only one system deployed in a timeframe
where 7.3 was relevant, and the "big systems" skipped over 7.3 much as
you did.
> We've only just today hit our first problem in 7.4, and it's fixed by
> upgrading to 7.4.current, rather than the 7.4.something we originally
> upgraded to from 7.2.something.
Ditto, to a degree; we hit a pretty funky index update thing that was
resolved in 7.4.8.
> We'll be skipping 8.0 completely and the next step will probably be to
> 8.1.something (or possibly 8.2.something, depending on how bizgres
> looks in 3 months time). We'd probably consider upgrading our
> customers more often, but a dump and restore is extremely painful.
We're strategizing somewhat similarly, save for bizgres not being on
our roadmap.
Dump and restore isn't forcibly necessary; we did the 7.2 to 7.4
upgrade via eRServer, and made sure that Slony-I was designed to
support upgrades.
I recently did an application upgrade (not a PG version change) using
Slony-I; replicated to a node that wasn't otherwise busy, and used
that node as the "base" where various tables were transformed into
their new forms. Replicated the "new forms" on everywhere. On the
"flag day," a MOVE SET shifted mastery, MERGE SET pasted things
together, and EXECUTE SCRIPT finished the transformation.
We're starting to look at 8.1, and would *certainly* use Slony-I to
perform that upgrade. The "on the cheap" method would involve
replacing nodes one at a time with 8.1 versions, though we'd more
likely have a bunch of 7.4 nodes running parallel with a corresponding
set of 8.1 nodes, and, once done, drop all the 7.4 ones at once...
> Just a view from the pg-based-enterprise-application world.
>
> A nice pg_upgrade utility would make a big difference. Clearly an
> in-place upgrade is possible, but maintaining is hard. There are two
> broad ways of running a pg_upgrade project - one that is entirely
> independent of the main codebase and one that puts requirements on
> the main codebase developers ("if you change $foo you provide code
> to translate old $foo to new $foo"). Any feel for the relative
> difficulty of the two approaches? And how much push-back there'd be
> on the latter?
This strikes me as being only marginally easier than the proverbial
desires for tools to convert ext2 to XFS or ReiserFS.
The conversion tool would have to encode a lot of hairy details, and
would require that the likes of Tom Lane and Bruce Momjian spend a lot
of their time writing the conversion tool instead of working on new
features.
With filesystems, it seems easier and cheaper to buy an extra disk
drive (what, $200?) and use something like rsync/unison to relatively
efficiently replicate the filesystem.
Slony-I is the PostgreSQL equivalent to rsync/unison, in this case.
Or you could look at Mammoth Replicator, if you prefer...
The replication approach allows Tom and Bruce to work on sexy new
features instead of forcing them into the data conversion mould...
--
select 'cbbrowne' || '@' || 'cbbrowne.com';
http://cbbrowne.com/info/slony.html
It's always darkest just before it gets pitch black.
Steve, > The only crystal ball involved is the assumption that if bizgres has > Neat Stuff(tm) that would be of widespread use in it's development > tree at that point then the odds are good that it, or something > functionally equivalent to it, will appear in the 8.2 development > tree. It certainly won't be because it hasn't been submitted. All features for Bizgres PostgreSQL (as opposed to the proprietary MPP) will be sent to -patches. The main difference will be the release schedule. --Josh
On Mon, 26 Sep 2005, Josh Berkus wrote: > Tom, > >> Or, as you say, we could take the viewpoint that there are commercial >> companies willing to take on the burden of supporting back releases, and >> the development community ought not spend its limited resources on doing >> that. I'm hesitant to push that idea very hard myself, because it would >> look too much like I'm pushing the interests of my employer Red Hat >> ... but certainly there's a reasonable case to be made there. > > Well, I think you know my opinion on this. Since there *are* commercial > companies available, I think we should use them to reduce back-patching > effort. I suggest that our policy should be: the community will patch two > old releases, and beyond that if it's convenient, but no promises. In other > words, when 8.1 comes out we'd be telling 7.3 users "We'll be patching this > only where we can apply 7.4 patches. Otherwise, better get a support > contract." > > Of course, a lot of this is up to individual initiative; if someone fixes a > patch so it applies back to 7.2, there's no reason not to make it available. > However, there's no reason *you* should make it a priority. Agreed ... "if its convient/easy to back patch, cool ... but don't go out of your way to do it" ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
scrappy@postgresql.org ("Marc G. Fournier") writes:
> On Mon, 26 Sep 2005, Josh Berkus wrote:
>
>> Tom,
>>
>>> Or, as you say, we could take the viewpoint that there are commercial
>>> companies willing to take on the burden of supporting back releases, and
>>> the development community ought not spend its limited resources on doing
>>> that. I'm hesitant to push that idea very hard myself, because it would
>>> look too much like I'm pushing the interests of my employer Red Hat
>>> ... but certainly there's a reasonable case to be made there.
>>
>> Well, I think you know my opinion on this. Since there *are*
>> commercial companies available, I think we should use them to reduce
>> back-patching effort. I suggest that our policy should be: the
>> community will patch two old releases, and beyond that if it's
>> convenient, but no promises. In other words, when 8.1 comes out we'd
>> be telling 7.3 users "We'll be patching this only where we can apply
>> 7.4 patches. Otherwise, better get a support contract."
>>
>> Of course, a lot of this is up to individual initiative; if someone
>> fixes a patch so it applies back to 7.2, there's no reason not to
>> make it available. However, there's no reason *you* should make it a
>> priority.
>
> Agreed ... "if its convient/easy to back patch, cool ... but don't go
> out of your way to do it" ...
We're looking at Slony-I the same way.
The earliest version it ever did support was 7.3.4.
Some effort has had to go into making sure it continues to support
7.3.x, and, as of today's check-ins, there is *some* functionality
which is lost if you aren't running at least 7.4.
At some point, it will make sense to drop 7.3 support, but since
Slony-I has, as a common use-case, assisting to upgrade to newer
versions, I'm loathe to drop it arbitrarily.
One happy part of that is that it doesn't mean that 7.3 becomes
*totally* unsupported, as major releases such as 1.0.5 and 1.1.0 *do*
support it, and I wouldn't feel horribly badly if direct support
ceased in 1.2 as long as this left people with old databases the
option of using Slony-I 1.1 to upgrade from PG 7.3 to 8.1, at which
point they could get Newer, Better Slony-I 1.3 stuff via upgrading
just on the 8.1 instances.
Of course, there hasn't been anything *SO* substantial changed that it
has become tempting enough to drop 7.3 support. There have
occasionally been suggestions to add some 8.0-specific functionality;
when plenty of people are still using 7.4, that just doesn't tempt
:-).
--
let name="cbbrowne" and tld="cbbrowne.com" in String.concat "@" [name;tld];;
http://www3.sympatico.ca/cbbrowne/linux.html
"There is nothing in the world more helpless and irresponsible and
depraved than a man in the depths of an ether binge."
-- Dr. Hunter S. Thompson
On Mon, Sep 26, 2005 at 09:07:45PM -0700, Joshua D. Drake wrote:
>
> >A nice pg_upgrade utility would make a big difference. Clearly an
> >in-place upgrade is possible, but maintaining is hard. There are two
> >broad ways of running a pg_upgrade project - one that is entirely
> >independent of the main codebase and one that puts requirements on the
> >main codebase developers ("if you change $foo you provide code to
> >translate old $foo to new $foo"). Any feel for the relative difficulty
> >of the two approaches? And how much push-back there'd be on the latter?
> >
> >
> You can do in place upgrades with Slony-I and Mammoth Replicator.
With a lot more effort than a dump/restore, or presumably a pg_upgrade.
I'd love to see a project that uses Slony to do an in-place migration as
easy as possible. Maybe I'll get around to it in another 5 years....
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
On Mon, Sep 26, 2005 at 08:54:49PM -0700, Josh Berkus wrote: > Tom, > > >Or, as you say, we could take the viewpoint that there are commercial > >companies willing to take on the burden of supporting back releases, and > >the development community ought not spend its limited resources on doing > >that. I'm hesitant to push that idea very hard myself, because it would > >look too much like I'm pushing the interests of my employer Red Hat > >... but certainly there's a reasonable case to be made there. > > Well, I think you know my opinion on this. Since there *are* commercial > companies available, I think we should use them to reduce back-patching > effort. I suggest that our policy should be: the community will patch > two old releases, and beyond that if it's convenient, but no promises. > In other words, when 8.1 comes out we'd be telling 7.3 users "We'll be > patching this only where we can apply 7.4 patches. Otherwise, better > get a support contract." I agree, although I think there should be some time guarantees as well. I like the ~3 year number that's been tossed around. > Of course, a lot of this is up to individual initiative; if someone > fixes a patch so it applies back to 7.2, there's no reason not to make > it available. However, there's no reason *you* should make it a priority. Yeah, I hope that commercial interests can work together on supporting things they want supported. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461