Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.3(EOL)
-
None
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
|
Attachments
Issue Links
- relates to
-
-
- Open
-
Activity
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.
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.