List:Commits« Previous MessageNext Message »
From:Konstantin Osipov Date:September 22 2010 8:29am
Subject:Re: bzr commit into mysql-5.1-bugteam branch (Sergey.Glukhov:3467)
Bug#54494
View as plain text  
* Sergey Glukhov <Sergey.Glukhov@stripped> [10/07/07 15:16]:

The patch is OK to push, see below.

>  3467 Sergey Glukhov	2010-07-07
>       Bug#54494 crash with explain extended and prepared statements
>       In case of outer join and emtpy WHERE conditon
>       'always true' condition is created for WHERE clasue.
>       Later in mysql_select() original SELECT_LEX WHERE
>       condition is overwritten with created cond.
>       However SELECT_LEX condition is also used as inital
>       condition in mysql_select()->JOIN::prepare().
>       On second execution of PS modified SELECT_LEX condition
>       is taken and it leads to crash.
>       The fix is to restore original SELECT_LEX condition
>       (set to NULL if original cond is NULL) in
>       reinit_stmt_before_use().
>       HAVING clause is fixed too for safety reason
>       (no test case as I did not manage to think out
>        appropriate example).
>      @ mysql-test/r/ps.result
>         test case
>      @ mysql-test/t/ps.test
>         test case
>      @ sql/sql_prepare.cc
>         restore original SELECT_LEX condition
>         (set to NULL if original cond is NULL) in
>         reinit_stmt_before_use()

Davi,

the changes you requested in your review, I believe,
should be done in scope of optimizer re-engineering.

The additional tests for sel->prep_where and
sel->prep_having mechanism are present in ps.test,
they are added after each new discovered crash ;)

We indeed modify sel->where/having on many occasions
during join optimization, and restore these
subtrees upon next execution from a copy.

Gluh's patch is fixing this restoration mechanism,
which only worked when the original WHERE clause
was not NULL. I.e. it is a bug in the
reinit_stmt_before_use() that it doesn't set
where/having to their original value
if this value was NULL.

The bug wasn't hit before because there was 
an assumption that these parse subtrees are never
transformed from empty to non-empty values.
EXPLAIN EXTENDED is a case which breaks
this assumption.

Gluh's patch fixes this bug.
I therefore approve it.

-- 
Thread
bzr commit into mysql-5.1-bugteam branch (Sergey.Glukhov:3467)Bug#54494Sergey Glukhov7 Jul
  • Re: bzr commit into mysql-5.1-bugteam branch (Sergey.Glukhov:3467)Bug#54494Davi Arnaut9 Jul
    • Re: bzr commit into mysql-5.1-bugteam branch (Sergey.Glukhov:3467)Bug#54494Sergey Glukhov19 Aug
      • Re: bzr commit into mysql-5.1-bugteam branch (Sergey.Glukhov:3467)Bug#54494Davi Arnaut6 Sep
        • Re: bzr commit into mysql-5.1-bugteam branch (Sergey.Glukhov:3467)Bug#54494Sergey Glukhov17 Sep
  • Re: bzr commit into mysql-5.1-bugteam branch (Sergey.Glukhov:3467)Bug#54494Konstantin Osipov22 Sep
    • Re: bzr commit into mysql-5.1-bugteam branch (Sergey.Glukhov:3467)Bug#54494Davi Arnaut23 Sep
      • Re: bzr commit into mysql-5.1-bugteam branch (Sergey.Glukhov:3467)Bug#54494Konstantin Osipov24 Sep