Hi Fraser, Thats a famous one (I like it - you probably wont ;-)
It means that your hard disk (partition) is full. http://www.knowd.co.jp/staff/nils/mysql-error-codes.html Best regards Nils Valentin Tokyo/Japan 2003年 6月 6日 金曜日 10:27、Fraser MacKenzie さんは書きました: > 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. -- ================================================ Valentin Nils Internet Technology E-Mail: [EMAIL PROTECTED] URL: http://www.knowd.co.jp ================================================ -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
