Can we revisit the thought of PostgreSQL 7.2.4? 
Author Message
 Can we revisit the thought of PostgreSQL 7.2.4?

Hi everyone,

Over the last few days we've had patches submitted for 7.2.3 that
address a couple of things, both the WAL Recovery Bug that Tom has
developed a patch for, and a couple of buffer overflows that have been
widely reported.

Although we haven't wanted to release a 7.2.4, and have instead
encouraged people to upgrade to 7.3.x, there are places out there who's
applications aren't compatible with 7.3.x and would also need to upgrade
them as well.

It might be a really good idea if we re-visit the thought of 7.2.4 and
have something that people running the 7.2.x series can use safely until
they are able to move to 7.3.x or above.

What would it take, and apart from patches for the buffer overflows and
the WAL recovery bug, should anything else be included to ensure safety
and stability?

:-)

Regards and best wishes,

Justin Clift

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://www.***.com/



Tue, 05 Jul 2005 11:51:31 GMT
 Can we revisit the thought of PostgreSQL 7.2.4?


Quote:
> Although we haven't wanted to release a 7.2.4, and have instead
> encouraged people to upgrade to 7.3.x, there are places out there who's
> applications aren't compatible with 7.3.x and would also need to upgrade
> them as well.

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?
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster



Wed, 06 Jul 2005 12:48:47 GMT
 Can we revisit the thought of PostgreSQL 7.2.4?

Quote:

> 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 e{*filter*}d 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?

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.

                        regards, tom lane
                        Red Hat Database project

PS: I'm not taking a position on Justin's suggestion that there should
be a 7.2.4.  Marc and Bruce would be the ones who have to do the work,
so they get to make the decision...

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command



Wed, 06 Jul 2005 13:09:07 GMT
 Can we revisit the thought of PostgreSQL 7.2.4?

Quote:

> 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.

>                    regards, tom lane
>                    Red Hat Database project

> PS: I'm not taking a position on Justin's suggestion that there should
> be a 7.2.4.  Marc and Bruce would be the ones who have to do the work,
> so they get to make the decision...

Who, us?  Well, there is the confusion factor of releasing a patch to a
superceeded major version.  Wrapping it up and putting it out really
isn't a big deal.  Marc?

--
  Bruce Momjian                        |  http://candle.pha.pa.us

  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate

message can get through to the mailing list cleanly



Wed, 06 Jul 2005 13:16:21 GMT
 Can we revisit the thought of PostgreSQL 7.2.4?

Quote:

> > 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 e{*filter*}d 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.

Quote:
> 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

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command



Wed, 06 Jul 2005 14:41:26 GMT
 Can we revisit the thought of PostgreSQL 7.2.4?

Quote:

> ... 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?

Because there are unfixable bugs in the older versions.  I see very
little point in issuing "security updates" that fix individual buffer
overruns, when anyone who has the SQL-level access needed to trigger
one of those overruns can equally easily do "select cash_out(2)".
The only fix for that is an upgrade to 7.3.

I don't by any means have a problem with Red Hat issuing maintenance
releases against old versions (nor, as I said, do I have any objection
to a 7.2.4 community release; I just said it wasn't my decision to make).
What I am questioning is the value of fixing some security holes when
there are bigger, unfixable ones right next door.  It wastes time that
could be spent on other work, and it may give DBAs a false sense of
security.  "Sure I'm safe; I just got the latest security patch from
Red Hat, so my 6.5.3 Postgres must be bulletproof now!"

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate

message can get through to the mailing list cleanly



Thu, 07 Jul 2005 00:13:34 GMT
 Can we revisit the thought of PostgreSQL 7.2.4?

Quote:

> > ... 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?
> Because there are unfixable bugs in the older versions.  I see very
> little point in issuing "security updates" that fix individual buffer
> overruns, when anyone who has the SQL-level access needed to trigger
> one of those overruns can equally easily do "select cash_out(2)".
> The only fix for that is an upgrade to 7.3.

And the cure might be worse than the disease; that is my point.

Quote:
> It wastes time that
> could be spent on other work, and it may give DBAs a false sense of
> security.  "Sure I'm safe; I just got the latest security patch from
> Red Hat, so my 6.5.3 Postgres must be bulletproof now!"

Red Hat issued a very detailed synopsis of what was fixed.  Also, one man's
wasted time is another man's time well spent.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate

message can get through to the mailing list cleanly



Thu, 07 Jul 2005 12:02:37 GMT
 Can we revisit the thought of PostgreSQL 7.2.4?
This is an interesting thought. My gut tells me it is a viable
opportunity for the corporate entities that offer support and wish to
have 'VAR' status.

This is just my opinion, but I view the core development group as pure
development, and the various people that resell or distribute PostgreSQL
as a for-profit business as those responsible for maintaining backward
support.

Maybe RedHat or PostgreSQL Inc can do this? It is a really good message,
"The best of open source, with on going support."

And not to re-open a can of worms, but if PostgreSQL could upgrade
without having to do a dump and restore, then this wouldn't really be an
issue.

Quote:

> Hi everyone,

> Over the last few days we've had patches submitted for 7.2.3 that
> address a couple of things, both the WAL Recovery Bug that Tom has
> developed a patch for, and a couple of buffer overflows that have been
> widely reported.

> Although we haven't wanted to release a 7.2.4, and have instead
> encouraged people to upgrade to 7.3.x, there are places out there
> who's applications aren't compatible with 7.3.x and would also need to
> upgrade them as well.

> It might be a really good idea if we re-visit the thought of 7.2.4 and
> have something that people running the 7.2.x series can use safely
> until they are able to move to 7.3.x or above.

> What would it take, and apart from patches for the buffer overflows
> and the WAL recovery bug, should anything else be included to ensure
> safety and stability?

> :-)

> Regards and best wishes,

> Justin Clift

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate

message can get through to the mailing list cleanly


Thu, 07 Jul 2005 21:19:47 GMT
 Can we revisit the thought of PostgreSQL 7.2.4?

Quote:

> This is an interesting thought. My gut tells me it is a viable
> opportunity for the corporate entities that offer support and wish to
> have 'VAR' status.

> This is just my opinion, but I view the core development group as pure
> development, and the various people that resell or distribute PostgreSQL
> as a for-profit business as those responsible for maintaining backward
> support.

> Maybe RedHat or PostgreSQL Inc can do this? It is a really good message,
> "The best of open source, with on going support."

Very interesting thought.  It could probably be done.  Oh, hang on...
Red Hat is taking that angle for now.  :-)

Quote:
> And not to re-open a can of worms, but if PostgreSQL could upgrade
> without having to do a dump and restore, then this wouldn't really be an
> issue.

That's not really true.  Have personally seen applications that places
use and rely on that are not yet compatible with v 7.3.x, because the
vendors of the applications compiled against something that was of
version 7.2.x, and doesn't work with version 7.3.x.

Now, that's not our fault, and not the fault of the places running the
applications, it's just part of how PostgreSQL is applied out in the
real world.

:-)

Regards and best wishes,

Justin Clift

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html



Thu, 07 Jul 2005 21:43:22 GMT
 Can we revisit the thought of PostgreSQL 7.2.4?

Quote:


<snip>
>>PS: I'm not taking a position on Justin's suggestion that there should
>>be a 7.2.4.  Marc and Bruce would be the ones who have to do the work,
>>so they get to make the decision...

> Who, us?  Well, there is the confusion factor of releasing a patch to a
> superceeded major version.  Wrapping it up and putting it out really
> isn't a big deal.  Marc?

Hi Marc,

Would you be ok with us releasing a 7.2.4?

:-)

Regards and best wishes,

Justin Clift

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster



Fri, 08 Jul 2005 00:20:29 GMT
 Can we revisit the thought of PostgreSQL 7.2.4?

Quote:

> Over the last few days we've had patches submitted for 7.2.3 that
> address a couple of things, both the WAL Recovery Bug that Tom has
> developed a patch for, and a couple of buffer overflows that have been
> widely reported.

The buffer overflows, IMHO, are not sufficient reason to release an
update. As Tom pointed out, there are lots of other, unpatched overflows
in 7.2.3 (and the whole class of vulnerability requires SQL access to
begin with).

As for the "WAL recovery bug", AFAIK no such bug has been reported "in
the last few days". Exactly what issue are you referring to?

Cheers,

Neil

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command



Fri, 08 Jul 2005 01:52:50 GMT
 
 [ 11 post ] 

 Relevant Pages 

1. Postgresql revisited. Some questions about the product

2. Can we revisit the thought of PostgreSQL 7.2.4?

3. Thinking about WinHelp Tools? Think $$$

4. Thinking about WinHelp Tools? Think $$$

5. Switching from inhouse to canned package.

6. Cans access2.0 engine access btrieve files?

7. MDX : Canned Report or OLAP

8. Canned PARADOX scripts?

9. Anyone know of some canned (cheap or free) DB performance testing software

10. bcp canned app

11. if you will promise Allahdad's swamp against cans, it will angrily depart the unit

12. canned code to get db on web quickly via perl or


 
Powered by phpBB® Forum Software