Re: Formatting Curmudgeons WAS: MMAP Buffers - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: Formatting Curmudgeons WAS: MMAP Buffers |
Date | |
Msg-id | BANLkTim8N2wPVN_k-+S0EvEGS5Y9Ss5ouA@mail.gmail.com Whole thread Raw |
In response to | Re: Formatting Curmudgeons WAS: MMAP Buffers (Bruce Momjian <bruce@momjian.us>) |
Responses |
Re: Formatting Curmudgeons WAS: MMAP Buffers
Re: Formatting Curmudgeons WAS: MMAP Buffers Re: Formatting Curmudgeons WAS: MMAP Buffers |
List | pgsql-hackers |
On Mon, May 9, 2011 at 11:25 AM, Bruce Momjian <bruce@momjian.us> wrote: > Greg Smith wrote: >> On 04/21/2011 12:39 PM, Robert Haas wrote: >> > In fact, I've been wondering if we shouldn't consider extending the >> > support window for 8.2 past the currently-planned December 2011. >> > There seem to be quite a lot of people running that release precisely >> > because the casting changes in 8.3 were so painful, and I think the >> > incremental effort on our part to extend support for another year >> > would be reasonably small. >> >> The pending EOL for 8.2 is the only thing that keeps me sane when >> speaking with people who refuse to upgrade, yet complain that their 8.2 >> install is slow. This last month, that seems to be more than usual "why >> does autovacuum suck so much?" complaints that would all go away with an >> 8.3 upgrade. Extending the EOL is not doing any of these users a >> favor. Every day that goes by when someone is on a version of >> PostgreSQL that won't ever allow in-place upgrade is just making worse >> the eventual dump and reload they face worse. The time spent porting to >> 8.3 is a one-time thing; the suffering you get trying to have a 2011 >> sized database on 2006's 8.2 just keeps adding up the longer you >> postpone it. > > Interesting. You could argue that once 8.3 is our earliest supported > release that we could even shrink the support window because the > argument "I can't dump/reload my data" would be gone. Personally, I think the support window is on the borderline of being too short already. There are several Linux distributions out there that offer 5-year support for certain releases. Even assuming they incorporate the latest version of PostgreSQL at the time they wrap the final release, it'll already be some months since we released that version, and that means we'll stop supporting that version of PostgreSQL before they stop supporting that release. I regularly have systems that run for 3 or 4 years without needing to be reinstalled, and they're not necessarily running the bleeding-edge version of PostgreSQL when first installed. So they, too, are on the trailing edge of our support. As much as I believe that 9.0 (and, now, 9.1) are the future and people should move to them, we can't enforce that. EOL doesn't necessarily drive people to move. If they're just running "yum update" they're going to get 8.whatever.latest, and that's out of support and missing relevant bug fixes, then it is. I haven't run into much 8.1 recently, but it seems there is still a decent chunk of 8.2 out there. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
pgsql-hackers by date: