[MDEV-29801] Inconsistent ER_TOO_BIG_ROWSIZE - Jira

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Major
Resolution: Not a Bug
Affects Version/s: 10.3(EOL), 10.4(EOL), 10.5, 10.6, 10.7(EOL), 10.8(EOL), 10.9(EOL), 10.10(EOL)
Fix Version/s: N/A
Component/s: Storage Engine - InnoDB
Labels:
None

Description

There are two parts here. The first part affects all versions, while the second part (the crash) is 10.7+. I've set affected versions to all as I expect that the crash is an aftermath of preceding inconsistency; but it really depends on how you want to categorize it, so please change the versions as you deem fit.

--source include/have_innodb.inc

SET @format= @@innodb_default_row_format;

CREATE TABLE t (pk int primary key,

 c01 text, c02 text, c03 text, c04 text, c05 text, c06 text,

 c07 text, c08 text, c09 text, c10 text, c11 text, c12 text

) ENGINE=InnoDB;

SET GLOBAL INNODB_DEFAULT_ROW_FORMAT= COMPACT;

ALTER TABLE t FORCE;

SELECT TABLE_NAME, ROW_FORMAT FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = 't';

SET FOREIGN_KEY_CHECKS=0, UNIQUE_CHECKS=0;

INSERT IGNORE INTO t VALUES

(1, REPEAT('x',4805), REPEAT('t',2211), REPEAT('u',974), REPEAT('e',871), REPEAT('z',224), REPEAT('j',978), REPEAT('n',190), REPEAT('t',888), REPEAT('x',32768), REPEAT('e',968), REPEAT('b',913), REPEAT('x',12107)),

(2, REPEAT('x',4805), REPEAT('t',2211), REPEAT('u',974), REPEAT('e',871), REPEAT('z',224), REPEAT('j',978), REPEAT('n',190), REPEAT('t',888), REPEAT('x',32768), REPEAT('e',968), REPEAT('b',913), REPEAT('x',12107));

# Cleanup

DROP TABLE t;

SET GLOBAL INNODB_DEFAULT_ROW_FORMAT= @format;

The first part is the ALTER being allowed to convert the table into COMPACT format (with a warning). If it's attempted via the explicit ROW_FORMAT=COMPACT, either in CREATE or in ALTER, they fail with an error; but with the implicit default row format it somehow goes through:

10.3 78030b67b9c
ALTER TABLE t FORCE;
Warnings:
Warning 139 Row size too large (> 8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline.
SELECT TABLE_NAME, ROW_FORMAT FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = 't';
TABLE_NAME ROW_FORMAT
t Compact

2022-10-15 19:24:54 9 [Warning] InnoDB: Cannot add field `c11` in table `test`.`#sql-10c1e7_9` because after adding it, the row size is 8714 which is greater than maximum allowed size (8126 bytes) for a record on index leaf page.

The following INSERT fails on 10.3-10.6 with ER_TOO_BIG_ROWSIZE, but on 10.7+ it crashes:

10.7 588efca237
#3 <signal handler called>
#4 0x000055d3af5fa1bd in trx_undo_report_row_operation (thr=0x6220000324d8, index=0x616000a29a20, clust_entry=0x6170000846a0, update=0x0, cmpl_info=0, rec=0x0, offsets=0x0, roll_ptr=0x0) at /home/jenkins/workspace/sandbox-elenst/Nightly-Build-CS/src/storage/innobase/trx/trx0rec.cc:2001
#5 0x000055d3af48e3a0 in row_ins_clust_index_entry_low (flags=0, mode=2, index=0x616000a29a20, n_uniq=1, entry=0x6170000846a0, n_ext=0, thr=0x6220000324d8) at /home/jenkins/workspace/sandbox-elenst/Nightly-Build-CS/src/storage/innobase/row/row0ins.cc:2674
#6 0x000055d3af490f0a in row_ins_clust_index_entry (index=0x616000a29a20, entry=0x6170000846a0, thr=0x6220000324d8, n_ext=0) at /home/jenkins/workspace/sandbox-elenst/Nightly-Build-CS/src/storage/innobase/row/row0ins.cc:3168
#7 0x000055d3af491975 in row_ins_index_entry (index=0x616000a29a20, entry=0x6170000846a0, thr=0x6220000324d8) at /home/jenkins/workspace/sandbox-elenst/Nightly-Build-CS/src/storage/innobase/row/row0ins.cc:3305
#8 0x000055d3af4929a8 in row_ins_index_entry_step (node=0x622000032108, thr=0x6220000324d8) at /home/jenkins/workspace/sandbox-elenst/Nightly-Build-CS/src/storage/innobase/row/row0ins.cc:3473
#9 0x000055d3af493359 in row_ins (node=0x622000032108, thr=0x6220000324d8) at /home/jenkins/workspace/sandbox-elenst/Nightly-Build-CS/src/storage/innobase/row/row0ins.cc:3619
#10 0x000055d3af494387 in row_ins_step (thr=0x6220000324d8) at /home/jenkins/workspace/sandbox-elenst/Nightly-Build-CS/src/storage/innobase/row/row0ins.cc:3759
#11 0x000055d3af4da903 in row_insert_for_mysql (mysql_rec=0x6190000f50c8 "", prebuilt=0x6220000319a0, ins_mode=ROW_INS_NORMAL) at /home/jenkins/workspace/sandbox-elenst/Nightly-Build-CS/src/storage/innobase/row/row0mysql.cc:1308
#12 0x000055d3af14f90a in ha_innobase::write_row (this=0x61d0002f94b8, record=0x6190000f50c8 "") at /home/jenkins/workspace/sandbox-elenst/Nightly-Build-CS/src/storage/innobase/handler/ha_innodb.cc:7906
#13 0x000055d3ae8bdd7b in handler::ha_write_row (this=0x61d0002f94b8, buf=0x6190000f50c8 "") at /home/jenkins/workspace/sandbox-elenst/Nightly-Build-CS/src/sql/handler.cc:7571
#14 0x000055d3adff2747 in write_record (thd=0x62b00017a218, table=0x6190000f4b98, info=0x7f2c3710bcd0, sink=0x0) at /home/jenkins/workspace/sandbox-elenst/Nightly-Build-CS/src/sql/sql_insert.cc:2190
#15 0x000055d3adfeaf4c in mysql_insert (thd=0x62b00017a218, table_list=0x6290001096a0, fields=..., values_list=..., update_fields=..., update_values=..., duplic=DUP_ERROR, ignore=true, result=0x0) at /home/jenkins/workspace/sandbox-elenst/Nightly-Build-CS/src/sql/sql_insert.cc:1146
#16 0x000055d3ae0a4c6c in mysql_execute_command (thd=0x62b00017a218, is_called_from_prepared_stmt=false) at /home/jenkins/workspace/sandbox-elenst/Nightly-Build-CS/src/sql/sql_parse.cc:4563
#17 0x000055d3ae0bb906 in mysql_parse (thd=0x62b00017a218, rawbuf=0x629000109238 "INSERT IGNORE INTO t VALUES \n(1, REPEAT('x',4805), REPEAT('t',2211), REPEAT('u',974), REPEAT('e',871), REPEAT('z',224), REPEAT('j',978), REPEAT('n',190), REPEAT('t',888), REPEAT('x',32768), REPEAT('e'"..., length=457, parser_state=0x7f2c3710ca20) at /home/jenkins/workspace/sandbox-elenst/Nightly-Build-CS/src/sql/sql_parse.cc:8014
#18 0x000055d3ae094401 in dispatch_command (command=COM_QUERY, thd=0x62b00017a218, packet=0x62900028f219 "INSERT IGNORE INTO t VALUES \n(1, REPEAT('x',4805), REPEAT('t',2211), REPEAT('u',974), REPEAT('e',871), REPEAT('z',224), REPEAT('j',978), REPEAT('n',190), REPEAT('t',888), REPEAT('x',32768), REPEAT('e'"..., packet_length=457, blocking=true) at /home/jenkins/workspace/sandbox-elenst/Nightly-Build-CS/src/sql/sql_parse.cc:1894
#19 0x000055d3ae09188b in do_command (thd=0x62b00017a218, blocking=true) at /home/jenkins/workspace/sandbox-elenst/Nightly-Build-CS/src/sql/sql_parse.cc:1407
#20 0x000055d3ae4bb079 in do_handle_one_connection (connect=0x608000003038, put_in_cache=true) at /home/jenkins/workspace/sandbox-elenst/Nightly-Build-CS/src/sql/sql_connect.cc:1416
#21 0x000055d3ae4baa3a in handle_one_connection (arg=0x608000002fb8) at /home/jenkins/workspace/sandbox-elenst/Nightly-Build-CS/src/sql/sql_connect.cc:1318
#22 0x000055d3aef77726 in pfs_spawn_thread (arg=0x617000007098) at /home/jenkins/workspace/sandbox-elenst/Nightly-Build-CS/src/storage/perfschema/pfs.cc:2201
#23 0x00007f2c47a67ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#24 0x00007f2c47654aef in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Attachments

Issue Links

relates to

MDEV-29761 Bulk insert fails to rollback during insert..select

Closed

Activity

Ascending order - Click to sort in descending order

Thirunarayanan Balathandayuthapani added a comment - 2022-11-04 10:11

                        /* For ALTER TABLE...FORCE or OPTIMIZE TABLE,

                        we may only issue warnings, because there will

                        be no schema change from the user perspective. */

                        if (!info.row_size_is_acceptable(

                                    *index,

                                    !!(ha_alter_info->handler_flags

                                       & ~(INNOBASE_INPLACE_IGNORE

                                           | INNOBASE_ALTER_NOVALIDATE

                                           | ALTER_RECREATE_TABLE)))) {

                                error = DB_TOO_BIG_RECORD;

                                goto error_handling_drop_uncached_1;

Alter does give warning when it comes to ALTER..TABLE FORCE or OPTIMIZE TABLE because there is no schema change from user perspective.
marko If you have any suggestion then let me know.

Thirunarayanan Balathandayuthapani added a comment - 2022-11-04 10:11 /* For ALTER TABLE...FORCE or OPTIMIZE TABLE, we may only issue warnings, because there will be no schema change from the user perspective. */ if (!info.row_size_is_acceptable( *index, !!(ha_alter_info->handler_flags & ~(INNOBASE_INPLACE_IGNORE | INNOBASE_ALTER_NOVALIDATE | ALTER_RECREATE_TABLE)))) { error = DB_TOO_BIG_RECORD; goto error_handling_drop_uncached_1; } Alter does give warning when it comes to ALTER..TABLE FORCE or OPTIMIZE TABLE because there is no schema change from user perspective. marko If you have any suggestion then let me know.

Marko Mäkelä added a comment - 2022-11-04 10:42

thiru, the warning was intended for a scenario that the user had created a table in non-strict mode and then issues OPTIMIZE TABLE. The test case here is a little more involved, because the InnoDB internal schema is actually being changed from ROW_FORMAT=DYNAMIC to ROW_FORMAT=COMPACT even though no explicit ROW_FORMAT was specified.

I do not think that we can or should do much about the warning.

I would only fix the crash, which is related to ~~MDEV-24621~~ in 10.7. Ideally we would only reject the oversized row(s), but because the row-level undo logging has been disabled due to ~~MDEV-515~~, we may have to roll back the entire transaction.

How does 10.6 behave in this case? Already it should be using table-level undo logging here.

Marko Mäkelä added a comment - 2022-11-04 10:42 thiru , the warning was intended for a scenario that the user had created a table in non-strict mode and then issues OPTIMIZE TABLE . The test case here is a little more involved, because the InnoDB internal schema is actually being changed from ROW_FORMAT=DYNAMIC to ROW_FORMAT=COMPACT even though no explicit ROW_FORMAT was specified. I do not think that we can or should do much about the warning. I would only fix the crash, which is related to MDEV-24621 in 10.7. Ideally we would only reject the oversized row(s), but because the row-level undo logging has been disabled due to MDEV-515 , we may have to roll back the entire transaction. How does 10.6 behave in this case? Already it should be using table-level undo logging here.

Thirunarayanan Balathandayuthapani added a comment - 2022-11-04 10:57

10.7+ crash was addressed by ~~MDEV-29761~~ and added the test case too. I don't see any issue in 10.6 and it behaves as expected.

Thirunarayanan Balathandayuthapani added a comment - 2022-11-04 10:57 10.7+ crash was addressed by MDEV-29761 and added the test case too. I don't see any issue in 10.6 and it behaves as expected.

MariaDB Server

Inconsistent ER_TOO_BIG_ROWSIZE

Details

Description

Attachments

Issue Links

Activity

People

Dates

Git Integration