Re: Can we revisit the thought of PostgreSQL 7.2.4? - Mailing list pgsql-hackers

On Saturday 18 January 2003 00:08, Tom Lane wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > Incidentally, has anyone else noticed the security update onslaught from
> > Red Hat for older PostgreSQL versions?  They even backported the fixes to
> > 6.5.3 from Red Hat 6.2 (as well as for 7.0 and 7.1 as released in the
> > respective Red Hat Linux versions).  Should I forward that notice here?

> Some of the guys in Toronto got excited about it, but I can't see a lot
> of value there myself.  If you're still running 6.5.3, is it likely you
> notice updates from anywhere?

Why not?  Upgrading to another major version of most things isn't supported by 
Red Hat within a particular version.  KDE is a prime example.  GNOME is 
another.  XFree86 is another.  BIND is yet another, although BIND8 upgrades 
are available for the systems that shipped with BIND4.  RPM itself is one of 
the few exceptions.  Going to 7.3 from 6.5 is not an update.

And lots of sites are still running 6.2.  IIRC Red Hat's up2date automatic 
upgrader tool was available in 6.2, and I know other autoupdaters are 
available.  And, as we all know, automatic upgrade of PostgreSQL is only 
possible within a major version.  Plenty of security conscious people still 
run Red Hat 6.2.  Many probably pay for the enterprise support contracts 
through Red Hat, costing much money.

Hmmmph, I know of a user running a couple of sites still running 5.2, with no 
intention of upgrading those machines.  Will PostgreSQL 7.3 even build on Red 
Hat Linux 5.2?  Forced upgrades are nonsense.  So I'm glad Red Hat decided to 
put resources into supporting their userbase (even given the sunset on said 
support).

On the BSD front, OpenBSD in particular still is running ancient versions of 
some core network stuff, due to the extreme security nature of that OS.  Last 
I looked at OBSD it still shipped BIND4.  4.9 something.  Positively ancient 
code that they have thoroughly audited.  BIND8 hadn't at that time been fully 
audited.

> Red Hat 6.2 is still nominally supported (until March 31, it says here)
> so I suppose there's a corporate compulsion to back-patch anything
> that's labeled a security issue.  But let's get real ... PG 6.anything
> is stone-age code now.

Why?  If a user doesn't need the features of 7.x.x, and the codebase is 
working well for him/her, why should said user/DBA feel compelled to go 
through who knows what mechanations to upgrade to the latest version?  That's 
Microsoft-think.  The upgrade from a 6.5.3 system to a 7.3.1 system is likely 
to be traumatic at least and cataclysmic at worst (to upgrade PostgreSQL may 
require upgrading the whole OS, which may require more memory (maybe more 
memory than the motherboard will support, even)....).  Yes, let's get real -- 
not everybody needs or necessarily even wants all the improved features of PG 
7.3 versus even 6.5.

The 'corporate compulsion' you mentioned is more widely known as 'customer 
service.'  IOW, you want to stay in business, you support your customers.

The Red Hat 5.2 user mentioned previously is perfectly happy with the 
featureset of PostgreSQL 6.3.2 (which is what 5.2 shipped with) and won't 
upgrade until it's very necessary.  But this is a very low resource machine, 
where even the Linux 2.0 kernel makes sense.  Now 6.5.3 will build on 5.2, 
but I haven't tried anything more recent.  And 6.3.2 is enough database for 
their uses -- but these machines are in roles where security issues could be 
problematic.  If it were easier to upgrade, they might consider it. 
_Of_course_ I'm not advocating that _we_ support these old of systems (after 
all, the PostgreSQL Global Development Group _has_ no customers) -- but it 
_is_ nice when a distributor acknowledges their older customers with real 
security updates within their released versions, and doesn't force major 
upgrades when unnecessary.

Now if the user needs _features_ then the upgrade is justified, and I have no 
sympathy for a user who wants, say, schema support backpatched to 7.0.3, for 
instance.  That request is just ridiculous.  But for security and critical 
bugfixes, it should not be a forced major version upgrade, unless the bugfix 
cannot be easily backported.  I for one intend to get the source RPM's for 
the fixed packages -- who knows, maybe some of the patches include the 
ability to rebuild on later Red Hat Linux versions, helping my upgradability 
crusade a little.

As to the 7.2.4 issue, much if not all of our userbase is more than used to 
multiple concurrent OS kernel branches.  Linux users in particular are very 
used to parallel versions -- the 2.0.x and 2.2.x series still get occassional 
releases even with 2.4.x out, and the development versions are in parallel 
constantly (except during the first few versions of a recent stable) with 
stable releases..  FreeBSD has their branches, etc.  I think we should 
release a 7.2.4 if the bugfixes warrant it.  (Not a 7.1.4, though, or 7.0.4, 
or 6.5.4, or 6.4.3, or 6.3.3, or....)

And I'm not against progress -- just against forced progress.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11