Re: [CORE] [HACKERS] EOL for 7.4?
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Migration is really only half the story, or not even that much. Every time you move to a new Postgres version you have to do extensive work to revalidate your application. If you don't do that you're just asking for trouble. But it can be painful, expensive and disruptive. I know of places where it can take weeks or months of effort. So the less often you have to do it the better. This would be true even if we had had a perfect working inplace upgrade mechanism for years, which as you and Greg point out is not true. I don't agree with this - migration is much more important than you make out. Testing and validation can be a pain, but it can be done concurrently while your main production site is still chugging along and taking orders. At some point, however, migration *will* cause production downtime[1]. This is one of the Achilles' heel of Postgres, and I'm frankly surprised it has taken us this long to get pg_migrator to a somewhat working state. I don't have any clients who don't/can't upgrade because they can't manage the downtime, but I have more than one avoiding upgrade because of revalidation costs. Well, I certainly had many clients who had major problems dealing with the implicit casts removed in 8.3, but there are also some in which the sheer size of the database is a factor as well. I think Robert Treat can probably chime in on some upgrade woes here too. [1] Okay, there are some tricks to work around this or severely minimize the downtime /Bucardo_plug, but it's still a truism that upgrading versions is a pain and nearly always involves production downtime. - -- Greg Sabino Mullane g...@turnstep.com PGP Key: 0x14964AC8 200912040846 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAksZEqMACgkQvJuQZxSWSsgGyACdEyfIqwFsFrt9ZnQ2DNPVYIWP j08AoK+cLC84HSjlIbzJY8Gz/gAa6D74 =AzuV -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] EOL for 7.4?
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Mark wrote: Doesn't mean that packagers have to make new packages ... I personally think new packages shouldn't be made for anything older then *maybe* 3 releases (8.2, 8.3 and 8.4), but even that I think tends to be a bit excessive ... but doing source tar balls is easy enough ... Andrew wrote: But the issue for me is not what vendors support but how often we ask someone to upgrade if they want to stay on a community supported base. As I remarked before, other things being equal, I think five years is a reasonable interval, and given that many users don't upgrade right on a .0 release, I think a release lifetime of about six years is therefore about right as a target. All of this ignores a huge reason why we have an implicit obligation to support past releases for a long time: our horrible lack of an upgrade option. That's only now starting to get remedied somewhat with pg_migrator, Bucardo, and Slony, but the default way is still to do a dump-and-restore. Until we can make this process take minutes instead of days for large databases, people are going to end up stuck to what version they are on. Knowing they are going to have to do it all over again later is not going to be very confidence inspiring. Again, to emphasize: many people are using 7.4, or 8.0, or 8.1, not because they necessarily want to, but they can't easily afford the downtime to upgrade. Cutting them off arbitrarily early won't win us any friends. Once pg_migrator (or better, in-place upgrades) is working well, we can start setting EOL on versions based on number of years of some other criteria. - -- Greg Sabino Mullane g...@turnstep.com End Point Corporation PGP Key: 0x14964AC8 200912021218 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAksWokQACgkQvJuQZxSWSsg5kACfdd9nZtHSG/KcOAIOGxVZ81/o TUEAniaG4vWo4CY4v+3DlByJ4AZ6JXKP =MyN9 -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] EOL for 7.4?
On Wed, Dec 2, 2009 at 12:22 PM, Greg Sabino Mullane g...@turnstep.com wrote: Mark wrote: Doesn't mean that packagers have to make new packages ... I personally think new packages shouldn't be made for anything older then *maybe* 3 releases (8.2, 8.3 and 8.4), but even that I think tends to be a bit excessive ... but doing source tar balls is easy enough ... Andrew wrote: But the issue for me is not what vendors support but how often we ask someone to upgrade if they want to stay on a community supported base. As I remarked before, other things being equal, I think five years is a reasonable interval, and given that many users don't upgrade right on a .0 release, I think a release lifetime of about six years is therefore about right as a target. All of this ignores a huge reason why we have an implicit obligation to support past releases for a long time: our horrible lack of an upgrade option. That's only now starting to get remedied somewhat with pg_migrator, Bucardo, and Slony, but the default way is still to do a dump-and-restore. Until we can make this process take minutes instead of days for large databases, people are going to end up stuck to what version they are on. Knowing they are going to have to do it all over again later is not going to be very confidence inspiring. Again, to emphasize: many people are using 7.4, or 8.0, or 8.1, not because they necessarily want to, but they can't easily afford the downtime to upgrade. Cutting them off arbitrarily early won't win us any friends. Once pg_migrator (or better, in-place upgrades) is working well, we can start setting EOL on versions based on number of years of some other criteria. At the moment it doesn't seem likely that pg_migrator is *ever* going to support upgrading from 7.4 or 8.0 or 8.1 to any later version. I'm not saying that's good, but nobody's expressed much interest in making in-place upgrade work even from an 8.2 base, let alone any older version. For that matter, there's been no concerted effort to resolve the limitations of the 8.3 - 8.4 upgrade. It isn't technically impossible for the 8.3 - 8.5 path to be smoother than the current 8.3 - 8.4 path, but nobody seems excited about working on it. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] EOL for 7.4?
Dave Page wrote: On Tue, Dec 1, 2009 at 4:41 PM, Tom Lane t...@sss.pgh.pa.us wrote: ... 8.1 in RHEL5 ... +1 for letting 7.* and 8.0 die whenever no-one's motivated to bother supporting it anymore. Presumably you'll be on the hook until 2014 for 8.1 security patches I can't see the community wanting to support it for that long -1 for letting 8.1 die while someone major still supporting it, even if that means EOLing 8.2 before 8.1. As a PG user, it's confidence inspiring to see a project that can provide 7-years of support on a version. As a Red Hat customer, I'd feel happier if my database were not considered dead by the upstream community. It also feels more in the spirit of open-source to me -- where if one member is willing to put in work (Red Hat/Tom), the benefits are shared back; and in exchange the rest of the community can help with that contribution. I'm for EOLing *at least* 7.4 and 8.0 by January 2011, and I'm certainly not going to argue against doing the same for 8.1. Frankly, I think we could do 7.4 and maybe 8.0 six months earlier. I think the best would be to say 7.4 and 8.0 end in Jan 2011, and 8.1 switches to only high-priority security patches at that date. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] EOL for 7.4?
Robert Haas wrote: Again, to emphasize: many people are using 7.4, or 8.0, or 8.1, not because they necessarily want to, but they can't easily afford the downtime to upgrade. Cutting them off arbitrarily early won't win us any friends. Once pg_migrator (or better, in-place upgrades) is working well, we can start setting EOL on versions based on number of years of some other criteria. At the moment it doesn't seem likely that pg_migrator is *ever* going to support upgrading from 7.4 or 8.0 or 8.1 to any later version. Agreed. I'm not saying that's good, but nobody's expressed much interest in making in-place upgrade work even from an 8.2 base, let alone any older version. For that matter, there's been no concerted effort to resolve the limitations of the 8.3 - 8.4 upgrade. It isn't technically impossible for the 8.3 - 8.5 path to be smoother than the current 8.3 - 8.4 path, but nobody seems excited about working on it. Agreed. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] EOL for 7.4?
Robert Haas wrote: Again, to emphasize: many people are using 7.4, or 8.0, or 8.1, not because they necessarily want to, but they can't easily afford the downtime to upgrade. Cutting them off arbitrarily early won't win us any friends. Once pg_migrator (or better, in-place upgrades) is working well, we can start setting EOL on versions based on number of years of some other criteria. At the moment it doesn't seem likely that pg_migrator is *ever* going to support upgrading from 7.4 or 8.0 or 8.1 to any later version. I'm not saying that's good, but nobody's expressed much interest in making in-place upgrade work even from an 8.2 base, let alone any older version. For that matter, there's been no concerted effort to resolve the limitations of the 8.3 - 8.4 upgrade. It isn't technically impossible for the 8.3 - 8.5 path to be smoother than the current 8.3 - 8.4 path, but nobody seems excited about working on it. Migration is really only half the story, or not even that much. Every time you move to a new Postgres version you have to do extensive work to revalidate your application. If you don't do that you're just asking for trouble. But it can be painful, expensive and disruptive. I know of places where it can take weeks or months of effort. So the less often you have to do it the better. This would be true even if we had had a perfect working inplace upgrade mechanism for years, which as you and Greg point out is not true. I don't have any clients who don't/can't upgrade because they can't manage the downtime, but I have more than one avoiding upgrade because of revalidation costs. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] EOL for 7.4?
Greg Sabino Mullane g...@turnstep.com writes: This thread never got resolved. I think we can all agree that EOL for 7.4 is a when, not an if? Can we get -core to take a stance here and pick a date? I like the clean smooth lines of January 2011, and thus saying that 2010 is the last year in which we'll backpatch things to the 7.4 branch. But I'll stick to whatever core thinks is best. Just let the advocacy team know so we can start work on it. If we're going to set the date that far off, I'd be inclined to EOL 8.0 at the same time. It'll be six years old by then. You could make a good argument for nuking 8.1 at the same time --- it'll turn five in November 2010. Personally I'll still be on the hook for maintaining 8.1 in RHEL5 so I'd be just as happy to keep it alive a bit longer, but if the community doesn't want to deal with it that makes perfect sense. I have no personal commitment to 8.0 at all because Red Hat never shipped that in a RHEL release ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] EOL for 7.4?
On Tue, Dec 1, 2009 at 4:41 PM, Tom Lane t...@sss.pgh.pa.us wrote: Greg Sabino Mullane g...@turnstep.com writes: This thread never got resolved. I think we can all agree that EOL for 7.4 is a when, not an if? Can we get -core to take a stance here and pick a date? I like the clean smooth lines of January 2011, and thus saying that 2010 is the last year in which we'll backpatch things to the 7.4 branch. But I'll stick to whatever core thinks is best. Just let the advocacy team know so we can start work on it. If we're going to set the date that far off, I'd be inclined to EOL 8.0 at the same time. It'll be six years old by then. You could make a good argument for nuking 8.1 at the same time --- it'll turn five in November 2010. Personally I'll still be on the hook for maintaining 8.1 in RHEL5 so I'd be just as happy to keep it alive a bit longer, but if the community doesn't want to deal with it that makes perfect sense. I have no personal commitment to 8.0 at all because Red Hat never shipped that in a RHEL release ... Presumably you'll be on the hook until 2014 for 8.1 security patches for RHEL 5 (looking at http://www.redhat.com/security/updates/errata/)? I can't see the community wanting to support it for that long, so I'd suggest we can (respectfully) ignore your commitments in that regard. I'm for EOLing *at least* 7.4 and 8.0 by January 2011, and I'm certainly not going to argue against doing the same for 8.1. Frankly, I think we could do 7.4 and maybe 8.0 six months earlier. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] EOL for 7.4?
On Tue, 1 Dec 2009, Tom Lane wrote: Greg Sabino Mullane g...@turnstep.com writes: This thread never got resolved. I think we can all agree that EOL for 7.4 is a when, not an if? Can we get -core to take a stance here and pick a date? I like the clean smooth lines of January 2011, and thus saying that 2010 is the last year in which we'll backpatch things to the 7.4 branch. But I'll stick to whatever core thinks is best. Just let the advocacy team know so we can start work on it. If we're going to set the date that far off, I'd be inclined to EOL 8.0 at the same time. It'll be six years old by then. You could make a good argument for nuking 8.1 at the same time --- it'll turn five in November 2010. Personally I'll still be on the hook for maintaining 8.1 in RHEL5 so I'd be just as happy to keep it alive a bit longer, but if the community doesn't want to deal with it that makes perfect sense. I have no personal commitment to 8.0 at all because Red Hat never shipped that in a RHEL release ... Just curious, but since you do all the back patching as it is, and building the source tarballs is simple enough ... What are RedHats EOL dates for the various releases? Doesn't mean that packagers have to make new packages ... I personally think new packages shouldn't be made for anything older then *maybe* 3 releases (8.2, 8.3 and 8.4), but even that I think tends to be a bit excessive ... but doing source tar balls is easy enough ... Marc G. FournierHub.Org Hosting Solutions S.A. scra...@hub.org http://www.hub.org Yahoo:yscrappySkype: hub.orgICQ:7615664MSN:scra...@hub.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] EOL for 7.4?
Marc G. Fournier scra...@hub.org writes: What are RedHats EOL dates for the various releases? Dave already mentioned a public page for that: http://www.redhat.com/security/updates/errata/ Based on track record so far, Red Hat isn't going to care about anything but high-priority security issues towards the end of the life cycle, but theoretically I'm on the hook till 2014 for 8.1.x. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] EOL for 7.4?
is there a reason why we can't follow a similar 4+3 life cycle? packagers r produced for the first 4y after .0 release and only source updates for year 5 thru 7? if we could advertise such on the web, there would be no question as to when bug reports are accepted (n+4y) and when only security ... and after y7, it's just not supported at all ... that would kill packager requirements on 8.0, 8.1 (as of last month) and totally kill 7.4 as of nov '10 Sent from my iPhone On 2009-12-01, at 14:33, Tom Lane t...@sss.pgh.pa.us wrote: Marc G. Fournier scra...@hub.org writes: What are RedHats EOL dates for the various releases? Dave already mentioned a public page for that: http://www.redhat.com/security/updates/errata/ Based on track record so far, Red Hat isn't going to care about anything but high-priority security issues towards the end of the life cycle, but theoretically I'm on the hook till 2014 for 8.1.x. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] EOL for 7.4?
Scrappy wrote: is there a reason why we can't follow a similar 4+3 life cycle? packagers r produced for the first 4y after .0 release and only source updates for year 5 thru 7? if we could advertise such on the web, there would be no question as to when bug reports are accepted (n+4y) and when only security ... and after y7, it's just not supported at all ... that would kill packager requirements on 8.0, 8.1 (as of last month) and totally kill 7.4 as of nov '10 What packagers produce is surely up to them. If RedHat or Devrim or Dave want to produce a package that's their prerogative. And IMNSHO 4 years is too short a period for non-security bugs. We have seen odd behaviour issues past those dates. The time between these periodic debates seems to be getting shorter and shorter. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] EOL for 7.4?
Andrew Dunstan and...@dunslane.net writes: The time between these periodic debates seems to be getting shorter and shorter. No, this is just a continuation of the unresolved thread from a month or so ago. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] EOL for 7.4?
Tom Lane wrote: Personally I'll still be on the hook for maintaining 8.1 in RHEL5 so I'd be just as happy to keep it alive a bit longer, but if the community doesn't want to deal with it that makes perfect sense. Some people consider the extended support and easy upgrades of the RHEL5 versions valuable enough that they have a strong preference to use the version of PostgreSQL that ships with it. Right now, when such people ask me about using 8.1 in that context, I tell them while it would be better if they ran something more recent, the performance of that version is reasonable and the bugs they might run into aren't that serious. This is not the case at all for either 7.4 or 8.0, which have been completely indefensible as versions to consider deploying for quite some time already. -- Greg Smith2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] EOL for 7.4?
Greg Smith g...@2ndquadrant.com writes: Some people consider the extended support and easy upgrades of the RHEL5 versions valuable enough that they have a strong preference to use the version of PostgreSQL that ships with it. Right now, when such people ask me about using 8.1 in that context, I tell them while it would be better if they ran something more recent, the performance of that version is reasonable and the bugs they might run into aren't that serious. This is not the case at all for either 7.4 or 8.0, which have been completely indefensible as versions to consider deploying for quite some time already. Well, actually, if it's just what will RH support, I just today got launch commit on this: https://bugzilla.redhat.com/show_bug.cgi?id=489479 which might change things a bit. PG 8.1 will be *in* RHEL5 until 2014, but whether many people will still be using it is another question. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] EOL for 7.4?
Tom Lane wrote: Greg Smith g...@2ndquadrant.com writes: Some people consider the extended support and easy upgrades of the RHEL5 versions valuable enough that they have a strong preference to use the version of PostgreSQL that ships with it. Right now, when such people ask me about using 8.1 in that context, I tell them while it would be better if they ran something more recent, the performance of that version is reasonable and the bugs they might run into aren't that serious. This is not the case at all for either 7.4 or 8.0, which have been completely indefensible as versions to consider deploying for quite some time already. Well, actually, if it's just what will RH support, I just today got launch commit on this: https://bugzilla.redhat.com/show_bug.cgi?id=489479 which might change things a bit. PG 8.1 will be *in* RHEL5 until 2014, but whether many people will still be using it is another question. Having 8.4 available and supported in RHEL5 will be nice. Maybe it was spurred by the talk I gave on 8.4 a couple of weeks ago at RH HQ? (j/k). But the issue for me is not what vendors support but how often we ask someone to upgrade if they want to stay on a community supported base. As I remarked before, other things being equal, I think five years is a reasonable interval, and given that many users don't upgrade right on a .0 release, I think a release lifetime of about six years is therefore about right as a target. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] EOL for 7.4?
Tom Lane wrote: Well, actually, if it's just what will RH support, I just today got launch commit on this... What I was trying to suggest was that right now, there are situations where a new deployment on 8.1 is still completely reasonable and possible to justify in the Enterprise Linux space, whereas I don't know of any situation where 7.4/8.0 can be similarly defended as a good idea. That makes supporting 8.1 quite a bit more valuable to the community than the earlier releases IMHO. Moving forward, I was hoping that we all get RHEL6 as a deployment option in the not so distant future for a platform that integrates 8.4 from day one; I didn't think that deploying RHEL5 was going to be the only choice for too much longer. -- Greg Smith2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] EOL for 7.4?
Greg Smith g...@2ndquadrant.com writes: What I was trying to suggest was that right now, there are situations where a new deployment on 8.1 is still completely reasonable and possible to justify in the Enterprise Linux space, whereas I don't know of any situation where 7.4/8.0 can be similarly defended as a good idea. Okay, but how much of the argument for that hinges on it being the only thing Red Hat will support on RHEL5? Moving forward, I was hoping that we all get RHEL6 as a deployment option in the not so distant future for a platform that integrates 8.4 from day one; I didn't think that deploying RHEL5 was going to be the only choice for too much longer. I don't believe I'm allowed to say anything about RHEL6 release schedules. However, if you are paying attention to what has shipped in recent Fedora releases, it's not hard to figure out that it will have PG = 8.4. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] EOL for 7.4?
On Tue, 2009-12-01 at 17:14 -0500, Tom Lane wrote: However, if you are paying attention to what has shipped in recent Fedora releases, it's not hard to figure out that it will have PG = 8.4. I thought RHEL 6 would ship with 8.3. It will be perfect if it skips 8.3. -- Devrim GÜNDÜZ, RHCE Command Prompt - http://www.CommandPrompt.com devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz signature.asc Description: This is a digitally signed message part
Re: [CORE] [HACKERS] EOL for 7.4?
Tom Lane wrote: Greg Smith g...@2ndquadrant.com writes: What I was trying to suggest was that right now, there are situations where a new deployment on 8.1 is still completely reasonable and possible to justify in the Enterprise Linux space, whereas I don't know of any situation where 7.4/8.0 can be similarly defended as a good idea. Okay, but how much of the argument for that hinges on it being the only thing Red Hat will support on RHEL5? Sure, at some point in 2010, we may reach a point where it would be ill advised to build a new system using RHEL5/PG8.1. I was suggesting more that there are completely reasonable reasons to deploy 8.1 even right now in 2009, and people are doing so. That gives the release a lot more future than 7.4 and 8.0, which anyone sensible gave up on a while ago. I'm all for dropping those older ones, but I don't think getting more aggressive than that and bundling 8.1 in while you're at it is so wise. -- Greg Smith2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.com
