| Bug #2159 | UPDATE of LONGBLOB >= 16Megs corrupts table | ||
|---|---|---|---|
| Submitted: | 18 Dec 2003 11:10 | Modified: | 15 Jan 2004 12:33 |
| Reporter: | [ name withheld ] | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server | Severity: | S1 (Critical) |
| Version: | v4.0.15-standard | OS: | Linux (Linux/Windows) |
| Assigned to: | MySQL Verification Team | CPU Architecture: | Any |
[18 Dec 2003 11:25]
Guilhem Bichot
Verified on Linux with 4.0.17, with a 26MB file:
[guilhem@gbichot2 mysql-test]$ mysql1 --max-allowed-packet=128000000 Test
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 5 to server version: 4.0.17-debug-log
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
MASTER> set global max_allowed_packet=128000000;
Query OK, 0 rows affected (0.00 sec)
MASTER> CREATE TABLE Table1 (Data LONGBLOB);
Query OK, 0 rows affected (0.01 sec)
MASTER> INSERT INTO Table1 (Data) VALUES (NULL);
Query OK, 1 row affected (0.01 sec)
MASTER> UPDATE Table1 SET Data=LOAD_FILE("/m/grosse_table4");
Query OK, 1 row affected (0.53 sec)
Rows matched: 1 Changed: 1 Warnings: 0
MASTER> check table Table1;
+-------------+-------+----------+-------------------------+
| Table | Op | Msg_type | Msg_text |
+-------------+-------+----------+-------------------------+
| Test.Table1 | check | error | Found wrong record at 0 |
| Test.Table1 | check | error | Corrupt |
+-------------+-------+----------+-------------------------+
2 rows in set (1.89 sec)
[18 Dec 2003 11:41]
MySQL Verification Team
Yes I was able to repeat on XP too:
mysql> UPDATE Table1 SET Data=LOAD_FILE("c:/temp/mysql.zip");
Query OK, 1 row affected (1.88 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> UPDATE Table1 SET Data=LOAD_FILE("c:/temp/mysql.exe");
ERROR 1030: Got error 127 from table handler
[26 Dec 2003 9:26]
MySQL Verification Team
Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.
If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information
about accessing the source trees is available at
http://www.mysql.com/doc/en/Installing_source_tree.html
Additional info:
Fix should come in 4.0.18
[15 Jan 2004 12:33]
Michael Widenius
Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.
If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information
about accessing the source trees is available at
http://www.mysql.com/doc/en/Installing_source_tree.html
Additional info:
The fix will be in 4.0.18 and 4.1.2
Description: When performing an UPDATE to a LONGBLOB >= 16Megs, the Table becomes corrupt. I first discovered this when using the Connector/J and thought it was a problem with that. Further testing with the Command-Line Client yields similar results (as explained below). My guess is that it's actually a Server problem, but as I said in my previous bug report, I can't believe I'm the first to discover this. I didn't find anything in the Bug Database, but getting the correct search criteria may be the issue: The following is what the my.cnf/my.ini file looks like: [mysqld] set-variable=max_allowed_packet=128M The following is the commands used in the mysql client environment: CREATE DATABASE Test; USE Test; CREATE TABLE Table1 (Data LONGBLOB); INSERT INTO Table1 (Data) VALUES (NULL); UPDATE Table1 SET Data=LOAD_FILE("<some file >= 16M"); UPDATE Table1 SET Data=LOAD_FILE("<any file/any size"); First up: OS: RH 8.0 MySQL: v4.0.15-standard Results: The second UPDATE call would fail with 'ERROR 1030: Got error 127 from table handler' Next: OS: Windows 2000 MySQL: v4.0.16-nt Results: The second UPDATE call would fail with 'ERROR 1030: Got error 127 from table handler' You can replace that second UPDATE call with a SELECT and get the same result (ie. the table is corrupted). Also, the actual file size that first starts failing isn't exactly 16M (16777216), but 16777210 (6 bytes overhead?). How to repeat: Run the test as stated above.