Re: Known issues on PostgreSQL server 8.1.19 - Mailing list pgsql-bugs

From Tom Lane
Subject Re: Known issues on PostgreSQL server 8.1.19
Date
Msg-id 7523.1450399985@sss.pgh.pa.us
Whole thread Raw
In response to Re: Known issues on PostgreSQL server 8.1.19  (John R Pierce <pierce@hogranch.com>)
Responses Re: Known issues on PostgreSQL server 8.1.19  (Thomas Munro <thomas.munro@enterprisedb.com>)
Re: Known issues on PostgreSQL server 8.1.19  ("Millepied, Pascal (GE Healthcare)" <pascalmillepied@ge.com>)
List pgsql-bugs
John R Pierce <pierce@hogranch.com> writes:
> On 12/17/2015 8:30 AM, Millepied, Pascal (GE Healthcare) wrote:
>> We are using PostgreSQL server 8.1.19 in our product and as part of
>> SDLC activities,
>> we would like to know about the Known Issues present in this version.
>> Could you tell us if there is new known issue on this release since
>> last year?

> PostgreSQL 8.1 is long out of support and well past end of life. 8.1.19
> was released in 2009, the final 8.1 release was 8.1.23 was in 2010.

That means in particular that no one has even bothered to track "known
issues" in 8.1 since 2010.  It'd be a reasonable bet for example that many
of the issues that were fixed in 8.2 after 8.2.19 are also in 8.1, but no
one associated with the project has checked.  And 8.2 went out of support
a year later, so it'd only be a good guide to the next year's worth of
fixes.  It's not exactly uncommon for us to make fixes that go into all
active branches and would probably apply to older ones if we were still
supporting them.

I'd suggest close study of all the later minor-release release notes to
see what fixes might be applicable to 8.1.  Or perhaps your time would be
better spent on migrating to a newer release --- the performance and
feature gap between 8.1 and current Postgres is pretty wide.

            regards, tom lane

pgsql-bugs by date:

Previous
From: John R Pierce
Date:
Subject: Re: Known issues on PostgreSQL server 8.1.19
Next
From: Tom Lane
Date:
Subject: Re: BUG #13824: EXISTS sometimes uses seq scan instead of index