-
Roy Lyseng authored
The symptoms of this bug is sometimes an assertion, sometimes only a valgrind warning about "jump or move depends on uninitialised value" in do_copy_null(). The problem may occur when a derived table with an ORDER BY clause is merged into an outer query, when the columns from ORDER BY are not also referenced in outer query. The problem is due to missing to mark the column underlying "field2" in the read set of table t1. field2 is used in ORDER BY inside a derived table. field2 references a column from the SELECT list. But since fields from SELECT list in a derived table are not marked in the read_set when they are first resolved, we need to make sure those fields are marked when used for other purposes, such as in ORDER BY. Notice that we only want to mark columns when merging into an outermost query expression, and not into another derived table. Bug case is added to main.derived-no-prepared due to bug#26808862.
Roy Lyseng authoredThe symptoms of this bug is sometimes an assertion, sometimes only a valgrind warning about "jump or move depends on uninitialised value" in do_copy_null(). The problem may occur when a derived table with an ORDER BY clause is merged into an outer query, when the columns from ORDER BY are not also referenced in outer query. The problem is due to missing to mark the column underlying "field2" in the read set of table t1. field2 is used in ORDER BY inside a derived table. field2 references a column from the SELECT list. But since fields from SELECT list in a derived table are not marked in the read_set when they are first resolved, we need to make sure those fields are marked when used for other purposes, such as in ORDER BY. Notice that we only want to mark columns when merging into an outermost query expression, and not into another derived table. Bug case is added to main.derived-no-prepared due to bug#26808862.
Loading