I am using mysql 3.23.54 and am trying to repair the index, using myisamchk -o tablename.MY and am getting the following error:
- recovering (with keycache) MyISAM-table 'msg.MYI' Data records: 498802 myisamchk: Error writing file 'msg.TMD' (Errcode: 28) myisamchk: error: 28 when writing to datafile MyISAM-table 'msg.MYI' is not fixed because of errors Try fixing it by using the --safe-recover (-o) or the --force (-f) option However, I have tried -o -f, -r, -o, etc. and I always get the same error. Has anyone run into this, and if so, any idea how I get around it? Fraser On Thu, 5 Jun 2003, John Brooks wrote: > Using InnoDB on a large table (> 100,000,000 rows)... > Trying to get a count that should equal about 25,000,000. > Wasn't using that much memory. > Database crashes.... > Any idea? > > 030605 19:38:27 InnoDB: Assertion failure in thread 45068 in file > row0sel.c line 1977 > InnoDB: Failing assertion: len == DATA_ROW_ID_LEN > InnoDB: We intentionally generate a memory trap. > InnoDB: Send a detailed bug report to [EMAIL PROTECTED] > mysqld got signal 11; > This could be because you hit a bug. It is also possible that this binary > or one of the libraries it was linked against is corrupt, improperly built, > or misconfigured. This error can also be caused by malfunctioning hardware. > We will try our best to scrape up some info that will hopefully help > diagnose > the problem, but since we have already crashed, something is definitely > wrong > and this may fail. > > key_buffer_size=419430400 > read_buffer_size=104853504 > sort_buffer_size=2097144 > max_used_connections=3 > max_connections=100 > threads_connected=3 > It is possible that mysqld could use up to > key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections > = 2465391 K > bytes of memory > Hope that's ok; if not, decrease some variables in the equation. > > thd=0x87626c0 > Attempting backtrace. You can use the following information to find out > where mysqld died. If you see no messages after this, something went > terribly wrong... > Cannot determine thread, fp=0xbfe3e7b8, backtrace may not be correct. > Stack range sanity check OK, backtrace follows: > 0x80741ea > 0x829c1e8 > 0x814db1b > 0x80d1a58 > 0x80d4cbc > 0x80a6abd > 0x80a0e29 > 0x80a0ad3 > 0x80998e0 > 0x80a630d > 0x807ecfa > 0x808273b > 0x807de2d > 0x8083c5e > 0x807cfff > 0x829999c > 0x82cd0aa > New value of fp=(nil) failed sanity check, terminating stack trace! > Please read http://www.mysql.com/doc/en/Using_stack_trace.html and > follow instructions on how to resolve the stack trace. Resolved > stack trace is much more helpful in diagnosing the problem, so please do > resolve it > Trying to get some variables. > Some pointers may be invalid and cause the dump to abort... > thd->query at 0x8773000 = select count(*) from user_new where list_code = 18 > thd->thread_id=3 > > Successfully dumped variables, if you ran with --log, take a look at the > details of what thread 3 did to cause the crash. In some cases of really > bad corruption, the values shown above may be invalid. > > The manual page at http://www.mysql.com/doc/C/r/Crashing.html contains > information that should help you find out what is causing the crash. > > > > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
