Bug 233564
Summary: | Upgrade PostgreSQL to 8.2.x branch | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Robert Scheck <redhat-bugzilla> |
Component: | postgresql | Assignee: | Tom Lane <tgl> |
Status: | CLOSED NOTABUG | QA Contact: | David Lawrence <dkl> |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 5.0 | CC: | hhorak |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-03-26 20:05:02 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Robert Scheck
2007-03-23 09:06:04 UTC
Sorry, this is not going to happen because it goes directly against the entire concept of RHEL, namely to be a stable platform for the lifetime of a given RHEL release branch. You'll note that RHEL4 still ships with Postgres 7.4.x... At some point there will be an Application Stack offering for RHEL5, and I'd expect that it will include Postgres 8.2 (or maybe 8.3 depending on timing), but it's much too late to change what the base OS ships. Uhm...some time ago, some of the marketing or sales people put some information at redhat.com, that new features, development etc. will get backported (e.g. driver and kernel backports) into the current Red Hat Enterprise Linux release until the first 3-4 years (?) after publishing. Unfortunately, I can't find these nice sentences right now... The upstream project's policy on this is "only bug fixes in stable branches", and I fully agree with that. Red Hat has not got the manpower or interest to maintain a version of Postgres that diverges substantially from any of those maintained by upstream. Even if we did, the need for compatibility of on-disk files would tremendously limit what we could do. The kernel situation is quite a bit different, both in terms of available manpower and in terms of how much can be done without breaking userland ABI. |