[MDEV-30918] Test innodb.row_size_error_log_warnings_3 failed on s390x on warnings (row size / leaf node too large) Created: 2023-03-23  Updated: 2023-09-08

Status: Open
Project: MariaDB Server
Component/s: None
Affects Version/s: 10.11
Fix Version/s: 10.11

Type: Bug Priority: Major
Reporter: Otto Kekäläinen Assignee: Michael Widenius
Resolution: Unresolved Votes: 0
Labels: None

Attachments: PNG File Intel-compress.png     PNG File Intel-redundant.png     PNG File s390x-compress.png     PNG File s390x-redundant.png    
Issue Links:
Relates
relates to MDEV-27634 innodb_zip tests failing on s390x Closed

 Description   

While testing 10.11.2 I noticed the s390x build post test run in https://launchpadlibrarian.net/656785756/buildlog_ubuntu-lunar-s390x.mariadb_1%3A10.11.2-2~ubuntu23.04.1~1679287945.48be213fe75.dev.otto_BUILDING.txt.gz failed on:

innodb.row_size_error_log_warnings_3 '4k,innodb' w2 [ fail ]
        Test ended at 2023-03-20 15:37:05
 
CURRENT_TEST: innodb.row_size_error_log_warnings_3
mysqltest: At line 49: query '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' 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
#		table from older versions
#
set global innodb_compression_level=1;
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;
 
More results from queries before failure can be found in /<<PKGBUILDDIR>>/builddir/mysql-test/var/2/log/row_size_error_log_warnings_3.log
 
 - skipping '/<<PKGBUILDDIR>>/builddir/mysql-test/var/2/log/innodb.row_size_error_log_warnings_3-4k,innodb/'
 
Retrying test innodb.row_size_error_log_warnings_3, attempt(2/3)...
 
innodb.innodb-alter-nullable '16k,innodb' w3 [ pass ]    233
worker[2] > Restart  - not started
***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.



 Comments   
Comment by Ehsan Kiani Far [ 2023-07-25 ]

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?

Comment by Marko Mäkelä [ 2023-07-27 ]

Does this occur when using a patched zlib that makes use of the dfltcc instruction?

Comment by Ehsan Kiani Far [ 2023-07-27 ]

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".

Comment by Daniel Black [ 2023-08-14 ]

https://github.com/madler/zlib/pull/410/

Comment by Daniel Black [ 2023-09-08 ]

Monty - see this is fixed in your latest bb-10.5-monty branch.

Generated at Thu Feb 08 10:19:52 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.