Skip site navigation (1) Skip section navigation (2)

Re: [CORE] EOL for 7.4?

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org, pgsql-core(at)postgresql(dot)org
Subject: Re: [CORE] EOL for 7.4?
Date: 2009-12-01 23:19:19
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, Dec 1, 2009 at 10:40 PM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:

> 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.

I think 8.2 is the first release with a vacuum that doesn't completely
thrash your i/o. Also the first one where you could effectively use
partitioning because you could actually add and drop partitions. Also
the first one with concurrent index builds. I can't imagine supporting
recommending 8.1 for anything but a toy deployment today.

I still insist it's unrealistic to consider any of these, even 8.2, as
anything but "best effort" at this point. Declaring 8.0 "end of life"
today is implying that we haven't already been skipping fixing bugs in
it that would have required major changes. People running 8.1 and 8.2
should be given the truth that only really important bugs are going to
cause any significant development for these versions. Otherwise
they're only going to get fixes that are simple and small enough that
the patches from later versions apply cleanly without major code
changes. This isn't out of laziness, it's because we know there are
existing installations depending on these releases and we don't want
to risk breaking them with major chunks of new code or fixing bugs
some people could be relying on unwittingly.


In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2009-12-01 23:27:54
Subject: Re: Block-level CRC checks
Previous:From: Tom LaneDate: 2009-12-01 23:11:36
Subject: Re: Block-level CRC checks

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group