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: 407d949e0912011519s15f02624o78196a8ed7b59cc2@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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.

--
greg

In response to

Responses

Browse pgsql-hackers by date

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