) ROW_FORMAT=COMPRESSED, ENGINE=InnoDB' failed: ER_TOO_BIG_ROWSIZE (1118): Row size too large (> 1982). Changing some columns to TEXT or BLOB may help. In current row format, BLOB prefix of 0 bytes is stored inline.
The result from queries just before the failure was:
< snip >
test.t1 optimize note Table does not support optimize, doing recreate + analyze instead
test.t1 optimize status OK
Warnings:
Warning 139 Row size too large (> NNNN). 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.
ALTER TABLE t1 FORCE;
Warnings:
Warning 139 Row size too large (> NNNN). 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.
DROP TABLE t1;
SET @@global.log_warnings = 2;
#
# MDEV-20194 Warnings inconsistently issued upon CHECK on
***Warnings generated in error logs during shutdown after running tests: innodb.row_size_error_log_warnings_3 innodb.check_ibd_filesize
2023-03-20 15:37:04 8 [Warning] InnoDB: Cannot add field `col_3` in table `test`.`t1` because after adding it, the row size is 2396 which is greater than maximum allowed size (1982 bytes) for a record on index leaf page.
2023-03-20 15:37:04 8 [Warning] InnoDB: Cannot add field `col_3` in table `test`.`t1` because after adding it, the row size is 2396 which is greater than maximum allowed size (1982 bytes) for a record on index leaf page.
2023-03-20 15:37:04 8 [Warning] InnoDB: Cannot add field `col_3` in table `test`.`#sql-alter-3643a-8` because after adding it, the row size is 2396 which is greater than maximum allowed size (1982 bytes) for a record on index leaf page.
2023-03-20 15:37:04 8 [Warning] InnoDB: Cannot add field `col_3` in table `test`.`#sql-alter-3643a-8` because after adding it, the row size is 2396 which is greater than maximum allowed size (1982 bytes) for a record on index leaf page.
2023-03-20 15:37:04 8 [Warning] InnoDB: Cannot add field `col_3` in table `test`.`t1` because after adding it, the row size is 2396 which is greater than maximum allowed size (1982 bytes) for a record on index leaf page.
2023-03-20 15:37:04 8 [Warning] InnoDB: Cannot add field `col_3` in table `test`.`#sql-alter-3643a-8` because after adding it, the row size is 2396 which is greater than maximum allowed size (1982 bytes) for a record on index leaf page.
2023-03-20 15:37:04 8 [Warning] InnoDB: Cannot add field `col_3` in table `test`.`#sql-alter-3643a-8` because after adding it, the row size is 2396 which is greater than maximum allowed size (1982 bytes) for a record on index leaf page.
2023-03-20 15:37:04 8 [ERROR] InnoDB: Cannot add field `f9` in table `test`.`t1` because after adding it, the row size is 1680 which is greater than maximum allowed size (1583 bytes) for a record on index leaf page.
Hi folks,
I did an experiment related to this test failure and would like to share my result in case it could help.
I manually created the table and inserted the records just like the test
The checked the table status by running `SHOW TABLE status` command. On x64, the average row size was 409 while it was 1638 on s390x.
Check the screenshots for more details. Blue is x64 and green is s390x
Then I repeated the same experiment but this time I used `REDUNDANT` row format. This time I got average row size of 2457 on x64 and 9830 on s390x
in both case the row size is about 4 times larger on s390x. Do you know why it is happening and how to fix it?
Ehsan Kiani Far
added a comment - Hi folks,
I did an experiment related to this test failure and would like to share my result in case it could help.
I manually created the table and inserted the records just like the test
CREATE TABLE t1(
f1 INT , f2 CHAR (200), f3 CHAR (200),
f4 CHAR (200), f5 CHAR (200), f6 CHAR (200),
f7 CHAR (200), f8 CHAR (200), f9 CHAR (200),
f10 CHAR (200), PRIMARY KEY (f1, f2(20), f3(20), f4(20))
) ROW_FORMAT=COMPRESSED, ENGINE=InnoDB;
INSERT INTO t1 SELECT seq, repeat( 'a' , 200), repeat( 'b' , 200),
repeat( 'c' , 200), repeat( 'd' , 200),
repeat( 'd' , 200), repeat( 'e' , 200),
repeat( 'e' , 200), repeat( 'f' , 200),
repeat( 'g' , 200) FROM seq_1_to_20;
The checked the table status by running `SHOW TABLE status` command. On x64, the average row size was 409 while it was 1638 on s390x.
Check the screenshots for more details. Blue is x64 and green is s390x
Then I repeated the same experiment but this time I used `REDUNDANT` row format. This time I got average row size of 2457 on x64 and 9830 on s390x
in both case the row size is about 4 times larger on s390x. Do you know why it is happening and how to fix it?
Thanks @Marko Mäkelä for your response. I can test that but do you know how I could know if zlib uses dfltcc? Is it a specific version of zlib? I checked provided zlib packages in the official linux repositories but there were no information of dfltcc. The version I used on rhel9 was "zlib-devel 1.2.11-39".
Ehsan Kiani Far
added a comment - Thanks @Marko Mäkelä for your response. I can test that but do you know how I could know if zlib uses dfltcc? Is it a specific version of zlib? I checked provided zlib packages in the official linux repositories but there were no information of dfltcc. The version I used on rhel9 was "zlib-devel 1.2.11-39".
Bug
Major
Hi folks,
I did an experiment related to this test failure and would like to share my result in case it could help.
I manually created the table and inserted the records just like the test
) ROW_FORMAT=COMPRESSED, ENGINE=InnoDB;The checked the table status by running `SHOW TABLE status` command. On x64, the average row size was 409 while it was 1638 on s390x.
Check the screenshots for more details. Blue is x64 and green is s390x
Then I repeated the same experiment but this time I used `REDUNDANT` row format. This time I got average row size of 2457 on x64 and 9830 on s390x
in both case the row size is about 4 times larger on s390x. Do you know why it is happening and how to fix it?