Обсуждение: red hat/mysql fiasco
We should be nice and professional on holiday season but sorry, I couldn't help myself: at <http://freshmeat.net/news/2000/12/21/977385850.html> we can read "The MySQL packages shipped with Red Hat Linux 7 contained buggy assembler code. When compiled with optimization enabled, this code caused the database server to return bad results. Also, a case where you can crash the database by a specific, valid query has been fixed. Updated packages are available from updates.redhat.com. " Just to make it a little in-topic I would like to 1) thanks Core team and all hackers and packagers for never putting us into such trouble and 2) issue a vehement cry - PLEASE assure things will stay this way, and we can reasonably trust every release. I do believe 2001 will be the big year for PostgreSql. P.S. RedHat chose to ship a beta version of MySql with RH7, so I believe that's more their fault than MySql people - but indeed there must be also a serious flaw in source code. -- Alessio F. Bragadini alessio@albourne.com APL Financial Services http://village.albourne.com Nicosia, Cyprus phone: +357-2-755750 "It is more complicated than you think" -- The Eighth Networking Truth from RFC 1925
On Thu, Dec 21, 2000 at 11:46:33AM +0200, Alessio Bragadini wrote:
> "The MySQL packages shipped with Red Hat Linux 7 contained buggy
> assembler code. When compiled with optimization
> enabled, this code caused the database server to return bad results.
> P.S. RedHat chose to ship a beta version of MySql with RH7, so I believe
> that's more their fault than MySql people - but indeed there must be
> also a serious flaw in source code.
I would tend to think this would be a bug in gcc.
For instance, gcc (2.95.2 at least) produces buggy code involving "long
long int" under certain circumstances. Sure hope PostgreSQL doesn't use
"long long int" anywhere. Or someone might say that's a serious flaw in
the source code that gcc generated buggy assembler code.
[Actually, the beta version of the gcc compiler that RH is now shipping
with doesn't have this particular long long bug, but the latest official
release of gcc does.]
mrc
--
Mike Castle Life is like a clock: You can work constantly
dalgoda@ix.netcom.com and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc
We are all of us living in the shadow of Manhattan. -- Watchmen
> On Thu, Dec 21, 2000 at 11:46:33AM +0200, Alessio Bragadini wrote: > > "The MySQL packages shipped with Red Hat Linux 7 contained buggy > > assembler code. When compiled with optimization > > enabled, this code caused the database server to return bad results. > > > P.S. RedHat chose to ship a beta version of MySql with RH7, so I believe > > that's more their fault than MySql people - but indeed there must be > > also a serious flaw in source code. > > > I would tend to think this would be a bug in gcc. > > For instance, gcc (2.95.2 at least) produces buggy code involving "long > long int" under certain circumstances. Sure hope PostgreSQL doesn't use > "long long int" anywhere. Or someone might say that's a serious flaw in > the source code that gcc generated buggy assembler code. > > [Actually, the beta version of the gcc compiler that RH is now shipping > with doesn't have this particular long long bug, but the latest official > release of gcc does.] > > mrc actually I had that problem w/ assembler errors in my defualt install of redhat7. after fixing gcc that dissapeard. its definatly a bug in the version of gcc that redhat stupidly shiped but its not totaly unfixable. Mike
On Thu, Dec 21, 2000 at 11:23:32AM -0500, Mike Sears wrote:
> > [Actually, the beta version of the gcc compiler that RH is now shipping
> > with doesn't have this particular long long bug, but the latest official
> > release of gcc does.]
>
> actually I had that problem w/ assembler errors in my defualt install of
> redhat7. after fixing gcc that dissapeard.
>
> its definatly a bug in the version of gcc that redhat stupidly shiped but
> its not totaly unfixable.
Odd. I thought at least the long long bug was fixed in RH7's gcc "2.96"
(may be other bugs, true, but I thought long long wasn't one of them).
mrc
--
Mike Castle Life is like a clock: You can work constantly
dalgoda@ix.netcom.com and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc
We are all of us living in the shadow of Manhattan. -- Watchmen
On Thu, 21 Dec 2000, Alessio Bragadini wrote:
> "The MySQL packages shipped with Red Hat Linux 7 contained buggy
> assembler code. When compiled with optimization enabled, this code
> caused the database server to return bad results. Also, a case where
> you can crash the database by a specific, valid query has been fixed.
> Updated packages are available from updates.redhat.com. "
Mandrake packages for Postgresql are also flawed, in 7.2 at least. When
you cast some strings as timestamps, you can get weird values ("0:10:00"
-> "0:09:60"). It's also a compiler problem.
Fortunately, Postgresql-packaged RPMs for Mandrake don't have this
"feature".
--
Alvaro Herrera (<alvherre[@]protecne.cl>)
Alvaro Herrera wrote:
> On Thu, 21 Dec 2000, Alessio Bragadini wrote:
> Mandrake packages for Postgresql are also flawed, in 7.2 at least. When
> you cast some strings as timestamps, you can get weird values ("0:10:00"
> -> "0:09:60"). It's also a compiler problem.
> Fortunately, Postgresql-packaged RPMs for Mandrake don't have this
> "feature".
Could be a bad -O setting. The way RPM works in the build process
(which is, IMHO, not very good) means that typically the spec file that
controls the build sets the compilation options to include potentially
faulty combinations with certain programs.
Mandrake is known for aggressive -O settings.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Mike Castle <dalgoda@ix.netcom.com> writes: > On Thu, Dec 21, 2000 at 11:46:33AM +0200, Alessio Bragadini wrote: > > "The MySQL packages shipped with Red Hat Linux 7 contained buggy > > assembler code. When compiled with optimization > > enabled, this code caused the database server to return bad results. > > > P.S. RedHat chose to ship a beta version of MySql with RH7, so I believe > > that's more their fault than MySql people - but indeed there must be > > also a serious flaw in source code. > > > I would tend to think this would be a bug in gcc. No. That was our first thought as well. However, during the search for the bug we found that the bug was in their assembly code(aliasing). The patch was submitted by us. We also found a bug in their SPARC assembly, where they used a reserved register. -- Trond Eivind Glomsrød Red Hat, Inc.
Alessio Bragadini <alessio@albourne.com> writes: > P.S. RedHat chose to ship a beta version of MySql with RH7, so I believe > that's more their fault than MySql people - but indeed there must be > also a serious flaw in source code. We shipped the one we could ship - the latter ones are the only one with a free license. MySQL is not the database we recommend FTTB (that is PostgreSQL, and Oracle for higher end needs) and it is not a choice from the main menu. If you choose packages individually, you can MySQL but the "SQL Server" installation alternative gives you PostgreSQL. -- Trond Eivind Glomsrød Red Hat, Inc.