diff options
author | unknown <timour@askmonty.org> | 2013-01-14 15:05:05 +0200 |
---|---|---|
committer | unknown <timour@askmonty.org> | 2013-01-14 15:05:05 +0200 |
commit | cf79c01cc7b9071c68055c90659da58c3b3b7363 (patch) | |
tree | c7bd203557edb00ec786f360c0b08774e4c12080 /sql/add_errmsg | |
parent | edc89f7511ac924f1c3ce14b356894939dea58c0 (diff) | |
download | mariadb-git-cf79c01cc7b9071c68055c90659da58c3b3b7363.tar.gz |
Fix for bug MDEV-3992
Analysis:
The crash is a result of incorrect analysis of whether a secondary key
can be extended with a primary in order to compute ORDER BY. The analysis
is done in test_if_order_by_key(). This function doesn't take into account
that the primary key may in fact index the same columns as the secondary
key. For the test query test_if_order_by_key says that there is an extended
key with total 2 keyparts.
At the same time, the condition
if (pkinfo->key_part[i].field->key_start.is_set(nr))
in test_if_cheaper_oredring() becomes true for (i == 0), which results in
an invalid access to rec_per_key[-1].
Solution:
The best solution would be to reuse KEY::ext_key_parts that is already computed
by open_binary_frm(), however after detailed analysis the conclusion is that
the change would be too intrusive for a GA release.
The solution for 5.5 is to add a guard for the case when the 0-th key part is
considered, and to assume that all keys will be scanned in this case.
Diffstat (limited to 'sql/add_errmsg')
0 files changed, 0 insertions, 0 deletions