Details
-
Bug
-
Status: Open (View Workflow)
-
Critical
-
Resolution: Unresolved
-
10.11, 11.4, 11.8, 12.3, 13.0, 13.1, 13.2
Description
CLI Testcase:
# mysqld options required for replay: --max_allowed_packet=1073741824 |
CREATE TABLE t1 (a LONGBLOB, b LONGBLOB) ENGINE=MyISAM; |
INSERT INTO t1 VALUES (REPEAT('a',1073741824), REPEAT('b',1073741824)); |
SELECT LENGTH(a), LENGTH(b) FROM t1; |
MTR Testcase:
SET @save_max_allowed_packet= @@global.max_allowed_packet; |
SET GLOBAL max_allowed_packet= 1073741824; |
--connect (con1,localhost,root)
|
CREATE TABLE t1 (a LONGBLOB, b LONGBLOB) ENGINE=MyISAM; |
INSERT INTO t1 VALUES (REPEAT('a',1073741824), REPEAT('b',1073741824)); |
--disable_result_log
|
--error 0,ER_CRASHED_ON_USAGE
|
SELECT LENGTH(a), LENGTH(b) FROM t1; |
--enable_result_log
|
--let $err= $mysql_errno
|
DROP TABLE t1; |
if ($err) |
{
|
--die The INSERT of a 2 GB row into the MyISAM table succeeded, but the table now reads as crashed |
}
|
--disconnect con1
|
--connection default
|
SET GLOBAL max_allowed_packet= @save_max_allowed_packet; |
Leads to:
|
CS 13.1.2 87e62ca17270e163a6d41b3fc8d6f4d440f1bb88 (Optimized, Clang 22.1.8-20260622) Build 05/10/2026 |
mysqltest: At line 14: The INSERT of a 2 GB row into the MyISAM table succeeded, but the table now reads as crashed
|
The same statements in the client:
|
CS 13.1.2 87e62ca17270e163a6d41b3fc8d6f4d440f1bb88 (Optimized, Clang 22.1.8-20260622) Build 05/10/2026 |
ERROR 1194 (HY000) at line 4: Table 't1' is marked as crashed and should be repaired
|
|
CS 13.1.2 87e62ca17270e163a6d41b3fc8d6f4d440f1bb88 (Optimized, Clang 22.1.8-20260622) Build 05/10/2026 |
2026-10-06 18:53:14 5 [ERROR] Got error 127 when reading table './test/t1'
|
2026-10-06 18:53:14 5 [ERROR] mariadbd: Table 't1' is marked as crashed and should be repaired
|
REPAIR TABLE on that table:
|
CS 13.1.2 87e62ca17270e163a6d41b3fc8d6f4d440f1bb88 (Optimized, Clang 22.1.8-20260622) Build 05/10/2026 |
Table Op Msg_type Msg_text
|
test.t1 repair info Wrong bytesec: 13-128- 0 at 0; Skipped
|
test.t1 repair info Found link that points at 7016996765293437281 (outside data file) at 83886068
|
test.t1 repair info Found link that points at 7016996765293437281 (outside data file) at 100663280
|
test.t1 repair warning Number of rows changed from 1 to 0
|
test.t1 repair status OK
|
From the code it seems that mi_create() caps pack_reclength at INT_MAX32 for a blob with a four byte length (storage/myisam/mi_create.c:123-126) and keeps it as share.base.max_pack_length (storage/myisam/mi_create.c:562). The write path does not compare the row against that value. The read path does: in _mi_read_dynamic_record() a record longer than max_pack_length goes to panic (storage/myisam/mi_dynrec.c:1476), which gives error 127.
The same row goes into InnoDB, and into Aria in its default PAGE row format, and reads back in full.
Attachments
Issue Links
- relates to
-
MDEV-36858 MariaDB MyISAM secondary indexes silently break for tables > 10B rows
-
- Closed
-