Thread
-
red hat/mysql fiasco
Alessio Bragadini <alessio@albourne.com> — 2000-12-21T09:46:33Z
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 -
Re: red hat/mysql fiasco
Mike Castle <dalgoda@ix.netcom.com> — 2000-12-21T15:50:27Z
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 -
Re: red hat/mysql fiasco
Mike Sears <mike@neutrinostudios.com> — 2000-12-21T16:23:32Z
> 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
-
Re: red hat/mysql fiasco
Mike Castle <dalgoda@ix.netcom.com> — 2000-12-21T16:29:58Z
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 -
Re: red hat/mysql fiasco
Alvaro Herrera <alvherre@protecne.cl> — 2000-12-21T16:50:00Z
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>) -
Re: red hat/mysql fiasco
Lamar Owen <lamar.owen@wgcr.org> — 2000-12-21T19:58:08Z
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 -
Re: red hat/mysql fiasco
Trond Eivind Glomsrød <teg@redhat.com> — 2000-12-26T12:43:11Z
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.
-
Re: red hat/mysql fiasco
Trond Eivind Glomsrød <teg@redhat.com> — 2000-12-26T22:58:34Z
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.