summaryrefslogtreecommitdiff
path: root/sql/log_event_old.cc
diff options
context:
space:
mode:
authorSreeharsha Ramanavarapu <sreeharsha.ramanavarapu@oracle.com>2015-10-01 07:45:27 +0530
committerSreeharsha Ramanavarapu <sreeharsha.ramanavarapu@oracle.com>2015-10-01 07:45:27 +0530
commit415faa122b9c683661dafac82fff414fa6864151 (patch)
tree9c2c434f3d7aee19a50a28fcdd9de82f23d54bf7 /sql/log_event_old.cc
parentf83d9e4217827b4d0b078bc93dff7d8f173adbef (diff)
downloadmariadb-git-415faa122b9c683661dafac82fff414fa6864151.tar.gz
Bug #19434916: FATAL_SIGNAL IN ADD_KEY_EQUAL_FIELDS() WITH
UPDATE VIEW USING OUTER SUBQUERY Issue: ----- While resolving a column which refers to a table/view in an outer query, it's respecitve item object is marked with the outer query's select_lex object. But when the column refers to a view or if the column is part of a subquery in the HAVING clause, an Item_ref object is created. While the reference to the outer query is stored by the Item_ref object, the same is not stored in it's real_item. This creates a problem with the IN-TO-EXISTS optmization. When there is an index over the column in the inner query, it will be considered since the column's real_item object will be mistaken for a local field. This will lead to a crash. SOLUTION: --------- Under the current design, the only way to fix this issue is to check the reginfo.join_tab for a NULL value. If yes, the query should not be worrying about the key use. The testcase and comments added as part of the fix for Bug#17766653 have been backported.
Diffstat (limited to 'sql/log_event_old.cc')
0 files changed, 0 insertions, 0 deletions