| 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: | |
| Category: | MySQL Server: Optimizer | Severity: | S3 (Non-critical) |
| Version: | 5.1.30 | OS: | Any |
| Assigned to: | CPU Architecture: | Any | |
| Tags: | Contribution | ||
[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.

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; }