[MDEV-376] Wrong result (missing rows) with index_merge+index_merge_intersection, join, AND/OR conditions, InnoDB Created: 2012-07-02 Updated: 2013-01-28 Resolved: 2012-07-05 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | None |
| Affects Version/s: | 5.5.25 |
| Fix Version/s: | 5.5.27 |
| Type: | Bug | Priority: | Major |
| Reporter: | Elena Stepanova | Assignee: | Sergei Petrunia |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Description |
|
The following query
on test data returns 2 rows with index_merge=ON and index_merge_intersection=ON, and 3 rows otherwise. 3 rows is the correct result. bzr version-info
Could not reproduce on MariaDB 5.3 or MySQL trunk. Minimal optimizer_switch:
Full optimizer_switch (default):
EXPLAIN (with the minimal optimizer_switch):
Test case:
Expected result:
Actual result:
|
| Comments |
| Comment by Sergei Petrunia [ 2012-07-03 ] |
|
| Comment by Sergei Petrunia [ 2012-07-04 ] |
|
I've finally figured it out. The problem is caused by changes inside InnoDB/XtraDB. index_merge/intersection code does the following: . call handler->read_range_first(), which will call handler->index_read_map() or handler->index_read(). Call #4 is supposed to inform the storage engine about changes made by calls #2 and #3. InnoDB doesn't implement handler::column_bitmap_signal(), so it ignores call #4. ha_innobase::index_read_map() used to call build_template(), which would rebuilt row_prebuilt_t structure and take changed made by calls #3 and #4 into account. This doesn't happen anymore; current innodb in 5.5 will only build row_prebuilt_t structure in handler->index_init() call. As a result, read operations on the innodb table do not fill in values for columns requested by #3 and #4, which causes the WHERE condition to be evaluated incorrectly, and produce this bug. |
| Comment by Sergei Petrunia [ 2012-07-05 ] |
|
Fix pushed. |