From 51408489b192a15cfe1317d49439d066d22d7cc5 Mon Sep 17 00:00:00 2001 From: unknown Date: Wed, 23 Feb 2005 13:39:29 +0200 Subject: [PATCH] Fix for BUG#8576 The problem was in different representations of double variables depending on platform/compiler/compile options. In some cases double variables are represented by 64 bits (while in memory), or by 80 bits (while in FPU register). As a result equal values are not considered "==". As many sources point out, doubles should not be compared by '==' for this reason. This fix subtracts the scaled minimal double value X such that 1 + X != 1, to ensure that the inequality holds in any case. sql/opt_range.cc: Do not compare double values with == because they may have different representations. --- sql/opt_range.cc | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/sql/opt_range.cc b/sql/opt_range.cc index ceb9f97bbbc..4d7df479000 100644 --- a/sql/opt_range.cc +++ b/sql/opt_range.cc @@ -7027,8 +7027,12 @@ get_best_group_min_max(PARAM *param, SEL_TREE *tree) cur_group_key_parts, tree, cur_index_tree, cur_quick_prefix_records, have_min, have_max, &cur_read_cost, &cur_records); - - if (cur_read_cost < best_read_cost) + /* + If cur_read_cost is lower than best_read_cost use cur_index. + Do not compare doubles directly because they may have different + representations (64 vs. 80 bits). + */ + if (cur_read_cost < best_read_cost - (DBL_EPSILON * cur_read_cost)) { index_info= cur_index_info; index= cur_index;