Re: [CORE] EOL for 7.4? - Mailing list pgsql-hackers

From Greg Stark
Subject Re: [CORE] EOL for 7.4?
Date
Msg-id 407d949e0912011519s15f02624o78196a8ed7b59cc2@mail.gmail.com
Whole thread Raw
In response to Re: [CORE] EOL for 7.4?  (Greg Smith <greg@2ndquadrant.com>)
Responses Re: [CORE] EOL for 7.4?  (Greg Smith <greg@2ndquadrant.com>)
Re: [CORE] EOL for 7.4?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Dec 1, 2009 at 10:40 PM, Greg Smith <greg@2ndquadrant.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Block-level CRC checks
Next
From: Tom Lane
Date:
Subject: Re: Block-level CRC checks