Re: [CORE] EOL for 7.4?

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: [CORE] EOL for 7.4?
Дата
Msg-id 407d949e0912011519s15f02624o78196a8ed7b59cc2@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [CORE] EOL for 7.4?  (Greg Smith <greg@2ndquadrant.com>)
Ответы Re: [CORE] EOL for 7.4?  (Greg Smith <greg@2ndquadrant.com>)
Re: [CORE] EOL for 7.4?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Block-level CRC checks
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Block-level CRC checks