You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Bug#34616553: SEGV (Item_subselect::print() at sql/item_subselect.cc:833)
reported by ASan
For this problem to happen, it needs several conditions to be met:
1. A mergeable derived table having a subquery in select list which is
referenced by ORDER BY through an alias. This makes the ORDER BY reference
the select expression when it gets resolved.
2. Needs to have a subquery with the same name in the query block where the
derived table gets merged.
3. Needs to have window function referencing the subquery through an alias
in PARTITION BY or ORDER BY clause. This makes it take a special path while
resolving the ordering item to point to the view reference (from the merged
derived table) than the one in the select list.
When the derived table having the order by referencing the subquery in
select expression gets merged, order by is moved to the outer query block.
This makes another call to resolve the order by item. This time, it
cleans up the order by item since it resolves against the select list again.
Later, window function's partition by clause resolves against the
view reference pointing to the subquery which was deleted previously
leading to problems later during optimization.
Solution is to not do the resolving again for a merged order by expression.
We now have a check for a non constant expression that is already resolved
and for such a order by expression, we just add a hidden element to the
merged query block instead of re-resolving it.
Change-Id: Idf33bca4ae1db29bfc5fcdc7e768e3ca77109441
0 commit comments