At 12:42p -0400 on Sat, 26 Jul 2008, mos wrote:
> At 09:14 AM 7/26/2008, you wrote:
>> The reproducible part is very important, because without it, it's
>> suspect to be just your individual case, as with a bug in *your*
>> application code, your hardware, or generally something in your setup.
>
> Well, I thought it might be my code too. That's why when the memory
> table was built (without the index), I went to a SqlMgr and counted the
> rows. None of the rows were missing. Then I did an Alter Table and added
> one index to the memory table, and sure enough when it was finished 75%
> of the rows were missing and no error was reported. Only the rows for
> index values "A" to "E" were in the table so the indexing lost rows.
That suggests to me a couple of things, both bugs with MySQL:
- an out of memory error - MySQL should *not* fail, but tell you it
can't complete and return you to a known state. An RDBMS should
*never* lose data. Ever.
- a piece of data in one of the rows of processing that MySQL doesn't
like, and therefore gives unexpected results. This is definitely a
bug as this should not happen to begin with, and "An RDBMS should
*never* lose data. Ever."
Summary: I don't know what's up and have not encountered this. But if
you can, create a small test case that can reproduce the error. Then
fill out a bug at http://bugs.mysql.com/ . Loss of data is absolutely a
bug, and a critical one.
A quick (< 3min) perusal of the bugs currently open did return any
meaningful results.
Kevin
