[MDEV-14377] innodb_zip.cmp_per_index failed in buildbot, result length mismatch Created: 2017-11-13  Updated: 2018-04-18  Resolved: 2018-04-18

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB, Tests
Affects Version/s: 10.3
Fix Version/s: 10.2.15, 10.3.7

Type: Bug Priority: Major
Reporter: Alice Sherepa Assignee: Thirunarayanan Balathandayuthapani
Resolution: Fixed Votes: 0
Labels: None


 Description   

http://buildbot.askmonty.org/buildbot/builders/kvm-bintar-quantal-amd64/builds/8051/steps/test/logs/stdio

CURRENT_TEST: innodb_zip.cmp_per_index
--- /usr/local/mariadb-10.3.3-linux-x86_64/mysql-test/suite/innodb_zip/r/cmp_per_index.result	2017-11-10 16:20:59.000000000 +0200
+++ /usr/local/mariadb-10.3.3-linux-x86_64/mysql-test/suite/innodb_zip/r/cmp_per_index.reject	2017-11-10 20:37:10.445862447 +0200
@@ -91,11 +91,5 @@
 compress_ops	0
 compress_ops_ok	0
 uncompress_ops	6
-database_name	test
-table_name	t
-index_name	PRIMARY
-compress_ops	0
-compress_ops_ok	0
-uncompress_ops	5
 DROP TABLE t;
 SET GLOBAL innodb_cmp_per_index_enabled=default;
 
mysqltest: Result length mismatch



 Comments   
Comment by Marko Mäkelä [ 2018-04-06 ]

I do not think that this failure is specific to 10.3. The ROW_FORMAT=COMPRESSED code has been mostly unchanged since 5.5.

Comment by Thirunarayanan Balathandayuthapani [ 2018-04-13 ]

If the select query chooses the index 'b' then there is possibility for the issue to happen. It doesn't need
to access the clustered index. Right now, select query does that only. When we open the table, it eventually
opens the clustered index to update the stats. That;s why there is value for primary index.

I think we can adjust the test case to make fetch from primary index always.

Comment by Marko Mäkelä [ 2018-04-15 ]

Good analysis. FORCE INDEX should cure it. I think it should be done in MariaDB 5.5 already. If the test is missing or under a different name in MariaDB before 10.2, then the test should be added or renamed.

Comment by Marko Mäkelä [ 2018-04-17 ]

This looks OK to me, but please do it in the earliest applicable version instead of 10.3.
The test exists in 10.2 already. It is missing from 10.0 and 10.1.
I think that it suffices to modify the test in 10.2.

Generated at Thu Feb 08 08:13:04 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.