[MDEV-20531] innodb.temporary_table_optimization fails in buildbot on kvm-rpm-rhel8-ppc64le with wrong result Created: 2019-09-08  Updated: 2019-09-09  Resolved: 2019-09-09

Status: Closed
Project: MariaDB Server
Component/s: Tests
Affects Version/s: 10.3
Fix Version/s: 10.2.28, 10.3.18, 10.4.9

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Marko Mäkelä
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-20532 Tests fail massively in buildbot on r... Open

 Description   

http://buildbot.askmonty.org/buildbot/builders/kvm-rpm-rhel8-ppc64le/builds/120/steps/mtr/logs/stdio

10.3 f80e02e043103ab4e6ca12d9efffec6eb9aa3b74

innodb.temporary_table_optimization 'innodb' w4 [ fail ]
        Test ended at 2019-09-07 12:42:16
 
CURRENT_TEST: innodb.temporary_table_optimization
--- /usr/share/mysql-test/suite/innodb/r/temporary_table_optimization.result	2019-09-07 09:08:24.000000000 +0000
+++ /dev/shm/var/4/log/temporary_table_optimization.reject	2019-09-07 12:42:15.958074599 +0000
@@ -128,11 +128,9 @@
 alter table t1 add index sec_index(t1_f);
 explain select * from t1 where t1_f > 2.2;
 id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
-1	SIMPLE	t1	ALL	sec_index	NULL	NULL	NULL	4	Using where
+1	SIMPLE	t1	range	sec_index	sec_index	5	NULL	1	Using index condition
 select * from t1 where t1_f > 2.2;
 t1_i	t1_f
-2	2.2
-3	2.2
 4	4.4
 alter table t1 add column (t1_c char(10));
 select * from t1;
 
mysqltest: Result length mismatch



 Comments   
Comment by Marko Mäkelä [ 2019-09-09 ]

The float constant 2.2 does not have a finite binary presentation: it would be 0b11.001100110011….
In case there is some difference between POWER and other platforms regarding dealing such floating-point arithmetics, I will try using constants that are finite sums of powers of two.

Curiously, test failures of this kind have not occurred on 10.2.

Comment by Marko Mäkelä [ 2019-09-09 ]

It seems that 2.2>2.2 would (wrongly) hold on AMD64, but not on POWER. If I change the constant to 2.5, then 2.5>2.5 would not hold on AMD64 either, and I would get a similar result difference as in the Description.

I think that the correct course of action would be to insert the constant 2.5 into the column, and then compare t1_f>= 2.5.

Generated at Thu Feb 08 09:00:11 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.