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 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
