Bug #46296 potential bug in get_best_ror_intersect()
Submitted: 20 Jul 2009 2:48 Modified: 22 Jul 2009 22:57
Reporter: Zardosht Kasheff (OCA) Email Updates:
Status: Not a Bug Impact on me:
None 
Category:MySQL Server: Optimizer Severity:S3 (Non-critical)
Version:5.1.30 OS:Any
Assigned to: CPU Architecture:Any
Tags: Contribution

[20 Jul 2009 2:48] Zardosht Kasheff
Description:
near the beginning of get_best_ror_intersect(), there is this line of code in a for loop:

    if (!tree->ror_scans_map.is_set(idx))
      continue;

Before continuing, tree->n_ror_scans should be decremented. If not, then when the following is executed:
  my_qsort(tree->ror_scans, tree->n_ror_scans, sizeof(ROR_SCAN_INFO*),
           (qsort_cmp)cmp_ror_scan_info);

tree->n_ror_scans will be greater than the actual number of ror_scans in tree->ror_scans.

I saw this bug via code review. I do not know how to get this to hit via a test case.

How to repeat:
n/a

Suggested fix:
do the following:

    if (!tree->ror_scans_map.is_set(idx))
    {
      tree->n_ror_scans--;
      continue;
    }
[22 Jul 2009 20:11] Zardosht Kasheff
Oops, looks like this is not a bug. I misunderstood what the value of tree->n_ror_scans was. It seems to be the number of ror scans that are set, not the number that there are. Therefore there is no bug and this patch does not seem to be necessary.
[22 Jul 2009 22:57] MySQL Verification Team
Changing status according last comment.