lp:~maria-captains/maria/mysql-6.0-testing2

Branch merges

Propose for merging

No branches dependent on this one.

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

2820. By Sergey Petrunia on 2009-07-29

Apply Evgen's fix:

Bug#45174: Incorrectly applied equality propagation caused wrong result
on a query with a materialized semi-join.

Equality propagation is done after query execution plan is chosen. It
substitutes fields from tables being retrieved later for fields from tables
being retrieved earlier. Materialized semi-joins are exception to this rule.
For field which belongs to a table within a materialized semi-join, we can
only pick fields from the same semi-join.

Example: suppose we have a join order:

   ot1 ot2 SJ-Mat(it1 it2 it3) ot3

and equality ot2.col = it1.col = it2.col
If we're looking for best substitute for 'it2.col', we should pick it1.col
and not ot2.col.

For a field that is not in a materialized semi-join we must pick a field
that's not embedded in a materialized semi-join.

Example: suppose we have a join order:

    SJ-Mat(it1 it2) ot1 ot2

and equality ot2.col = ot1.col = it2.col
If we're looking for best substitute for 'ot2.col', we should pick ot1.col
and not it2.col, because when we run a join between ot1 and ot2
execution of SJ-Mat(...) has already finished and we can't rely on the value
of it*.*.

Now the Item_equal::get_first function accepts as a parameter a field being
substituted and checks whether it belongs to a materialized semi-join.
Depending on the check result a field to substitute for or NULL is returned.

The is_sj_materialization_strategy method is added to the JOIN_TAB class to
check whether JOIN_TAB belongs to a materialized semi-join.

2819. By Sergey Petrunia on 2009-07-08

BUG#31480: Incorrect result for nested subquery when executed via semi join
Make the fix work with prepared statements:
- in previous cset changed calloc to alloc, forgot to add bzero.

2818. By Sergey Petrunia on 2009-07-08

BUG#31480: Incorrect result for nested subquery when executed via semi join
Make the fix work with prepared statements:
- collect/save ancestor_used_tables and furthest_correlated_ancestor only at
  PREPARE phase (at execute() we are unable to tell what table_map the outer
  reference would tell. since it would be the same anyway, we save it at
  PREPARE phase)

2817. By Sergey Petrunia on 2009-07-06

BUG#42742: crash in setup_sj_materialization, Copy_field::set
- If a semi-join strategy covers certain [first_table; last_table]
  range in join order, do reset the sj_strategy member for all tables
  within the range, except the first one.
  Failure to do so caused EXPLAIN/execution code to try applying two
  strategies at once which would cause all kinds of undesired effects.

2816. By Sergey Petrunia on 2009-07-06

BUG#31480: Incorrect result for nested subquery when executed via semi join
- Post-push valgrind fix

2815. By Sergey Petrunia on 2009-07-06

BUG#31480: Incorrect result for nested subquery when executed via semi join

2814. By Sergey Petrunia on 2009-07-04

Better comments

2813. By Alexander Nozdrin <email address hidden> on 2009-07-02

Merge from azalea-bugfixing

2812. By Alexander Barkov <email address hidden> on 2009-07-02

Postfix for WL#4584 Internationalized number format
Problems:
- Crash when using format(x,y, NULL)
- valgrind warnings with format(x,y, char_column)
Fix:
- checking that locale_name is not NULL in Item_func_format::get_locale
- using c_ptr_safe() instead of c_ptr() when passing to
  my_locale_by_name().

2811. By Alexander Nozdrin <email address hidden> on 2009-07-01

Fix result file.