MySQL Bugs: #1715: error 127 from table handler on UPDATE / losing records

Bug #1715	error 127 from table handler on UPDATE / losing records
Submitted:	30 Oct 2003 12:58	Modified:	30 Nov 2003 18:02
Reporter:	[ name withheld ]	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server: MyISAM storage engine	Severity:	S2 (Serious)
Version:	4.0.15a	OS:	Linux (Linux)
Assigned to:		CPU Architecture:	Any

Description:
Our forum system was running fine on MySQL v3.23. After our provider switched  to v4.0.14 we got regularly errors "Got error 127 from table handler" and several records of one table disappeared (one at a time). The update to v4.0.15a brought slightly improvement, but we still lose records.

This always happens during updates on a text field:
UPDATE Users SET U_TempRead = 'XXX' WHERE U_Username = 'name'

Instead of the 'XXX' the text field is updated frequently and sometimes with a huge text like ',60432,,60443,,60448,,60450,,60463,,60465,,60471,,60495,' but much longer.

Thats the MySQL errorlog:
030915 21:35:53 Warning: Checking table: './dbXXX/Users'
030915 21:35:53 Warning: Recovering table: './dbXXX/Users'
030915 21:35:54 Note: Found 1784 of 1785 rows when repairing './dbXXX/Users'

I thought this problem sounds like something that was already fixed in v4.0.15 according to the bug-fix list:
"- Fixed rare bug in MYISAM introduced in 4.0.3 where the index file header was not updated directly after an UPDATE of split dynamic rows. The symptom was that the table had a corrupted delete-link if mysqld was shut down or the table was checked directly after the update."
"- Fixed overflow bug in MyISAM and ISAM when a row is updated in a table with a large number of columns and at least one BLOB/TEXT column"

Maybe there's a connection to the two points above?

How to repeat:
Do frequent UPDATEs with text varying in length on the field U_TempRead.

There were additional bug fixes in 4.0.16 that may impact your situation.  If at all possible you should upgrade to the latest release and see if the problem persists.

I have just tested a very heavy UPDATE load against TEXT columns using 4.0.16 and have not had any table corruption.

Same for me.
Lot of inserts/updates, but unable to reproduce (data are dynamic, no log)

Upgrading from 3.23 to 4.0.15 on linux RedHat8 
with mysql-standard-4.0.15-pc-linux-i686.tar.gz

The error occurs on:
SELECT * FROM MyTable WHERE ColumnInt1=4888 ORDER BY ColumnInt2 DESC LIMIT 0,1

Error reported:
1030: Got error 127 from table handler

mysql> desc MyTable;
+------------------+------+-----+-----------+-------+
| Type             | Null | Key | Default   | Extra |
+------------------+------+-----+-----------+-------+
| int(11) unsigned |      | PRI | 0         |       |
| int(11) unsigned |      |     | 0         |       |
| int(11) unsigned |      |     | 0         |       |
| int(11) unsigned |      |     | 0         |       |
| int(11) unsigned |      |     | 0         |       |
| int(11) unsigned |      | MUL | 0         |       |
| int(11) unsigned |      |     | 0         |       |
| varchar(40)      |      | UNI |           |       |
| varchar(20)      |      | MUL |           |       |
| varchar(255)     |      |     |           |       |
| varchar(255)     |      |     |           |       |
| int(11) unsigned |      |     | 60        |       |
| int(11) unsigned |      |     | 0         |       |
| varchar(10)      |      |     |           |       |
| int(11) unsigned |      |     | 0         |       |
| int(11) unsigned |      | MUL | 0         |       |
| varchar(255)     |      |     |           |       |
| varchar(255)     |      |     |           |       |
| varchar(255)     |      |     |           |       |
| varchar(255)     |      |     |           |       |
| varchar(255)     |      |     |           |       |
| varchar(255)     |      |     |           |       |
| varchar(255)     |      |     |           |       |
| varchar(255)     |      |     |           |       |
| varchar(255)     |      |     |           |       |
| varchar(255)     |      |     |           |       |
| varchar(255)     |      |     |           |       |
| int(11) unsigned |      | MUL | 0         |       |
| int(11) unsigned |      |     | 0         |       |
| int(11) unsigned |      |     | 0         |       |
| int(11) unsigned |      |     | 0         |       |
| int(11) unsigned |      |     | 0         |       |
| int(11) unsigned |      | MUL | 1         |       |
| int(11) unsigned |      |     | 0         |       |
| int(11) unsigned |      |     | 0         |       |
| int(11) unsigned |      |     | 0         |       |
| int(11) unsigned |      |     | 0         |       |
| int(11) unsigned |      |     | 0         |       |
| float(15,5)      |      |     | 0.00000   |       |
| int(11) unsigned |      |     | 0         |       |
| float(15,5)      |      |     | 0.00000   |       |
| float(15,5)      |      |     | 0.00000   |       |
| float(15,5)      |      |     | 0.00000   |       |
| float(15,5)      |      |     | 0.00000   |       |
| float(15,5)      |      |     | 0.00000   |       |
| varchar(255)     |      |     | GMT       |       |
| float(15,5)      |      |     | 100.00000 |       |
| float(15,5)      |      |     | 0.00000   |       |
| float(15,5)      |      |     | 0.00000   |       |
| int(11) unsigned |      |     | 1         |       |
| varchar(255)     |      |     |           |       |
| int(11) unsigned |      |     | 0         |       |
| int(11) unsigned |      |     | 0         |       |
| int(11) unsigned |      |     | 0         |       |
| int(11) unsigned |      |     | 0         |       |
+------------------+------+-----+-----------+-------+
55 rows in set (0.00 sec)

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".