From: | "Mike Sears" <mike(at)neutrinostudios(dot)com> |
---|---|
To: | "Mike Castle" <dalgoda(at)ix(dot)netcom(dot)com>, "General PostgreSQL discussion list" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: red hat/mysql fiasco |
Date: | 2000-12-21 16:23:32 |
Message-ID: | 002101c06b6a$63414060$1600000a@domain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Mike Castle | 2000-12-21 16:29:58 | Re: red hat/mysql fiasco |
Previous Message | Tom Lane | 2000-12-21 16:22:35 | Re: Could somebody EXPLAIN? :-) |