1. 31 May, 2006 1 commit
    • unknown's avatar
      Bug#19604 - CHECK TABLE with concurrent INSERT can reset auto_increment · 556defaf
      unknown authored
      CHECK TABLE did temporarily clear the auto_increment value.
      It runs with a read lock, allowing other readers and
      conurrent INSERTs. The latter could grab the wrong value
      in this moment.
      
      CHECK TABLE does no longer modify the auto_increment value.
      Not even for a short moment.
      
      
      myisam/mi_check.c:
        Bug#19604 - CHECK TABLE with concurrent INSERT can reset auto_increment
        In chk_key() and update_auto_increment_key() in the repair_only
        case, do not touch info->s->state.auto_increment. Especially
        chk_key() can be called from CHECK TABLE with a read lock.
        Concurrent inserts could grab a temporarily changed value.
        Added minor style fixes.
      myisam/mi_key.c:
        Bug#19604 - CHECK TABLE with concurrent INSERT can reset auto_increment
        Changed update_auto_increment() to retrieve_auto_increment()
        to reflect that it does not change the auto_increment by
        itself any more. This must now be done externally if needed.
      myisam/mi_update.c:
        Bug#19604 - CHECK TABLE with concurrent INSERT can reset auto_increment
        Added explicit update of info->s->state.auto_increment
        after the change from update_auto_increment() to
        retrieve_auto_increment().
      myisam/mi_write.c:
        Bug#19604 - CHECK TABLE with concurrent INSERT can reset auto_increment
        Added explicit update of info->s->state.auto_increment
        after the change from update_auto_increment() to
        retrieve_auto_increment().
      myisam/myisamdef.h:
        Bug#19604 - CHECK TABLE with concurrent INSERT can reset auto_increment
        Changed update_auto_increment() to retrieve_auto_increment()
        to reflect that it does not change the auto_increment by
        itself any more. This must now be done externally if needed.
      556defaf
  2. 07 May, 2006 10 commits
    • unknown's avatar
      Merge ibabaev@bk-internal.mysql.com:/home/bk/mysql-5.0 · 0eccfdd2
      unknown authored
      into  rurik.mysql.com:/home/igor/mysql-5.0
      
      
      mysql-test/r/rpl_user_variables.result:
        Auto merged
      sql/item_func.cc:
        Auto merged
      sql/sql_select.cc:
        Auto merged
      mysql-test/t/rpl_user_variables.test:
        Manual merge
      0eccfdd2
    • unknown's avatar
      Post-merge fixes. · 8b9596ac
      unknown authored
      8b9596ac
    • unknown's avatar
      Merge rurik.mysql.com:/home/igor/dev/mysql-4.1-0 · 02110c8f
      unknown authored
      into  rurik.mysql.com:/home/igor/dev/mysql-5.0-0
      
      
      mysql-test/r/having.result:
        Auto merged
      mysql-test/t/having.test:
        Auto merged
      sql/item_func.cc:
        Auto merged
      sql/sql_lex.h:
        Auto merged
      mysql-test/r/rpl_user_variables.result:
        Manual merge
      mysql-test/t/rpl_user_variables.test:
        Manual merge
      sql/sql_lex.cc:
        Manual merge
      sql/sql_prepare.cc:
        Manual merge
      sql/sql_select.cc:
        Manual merge
      02110c8f
    • unknown's avatar
      Merge ibabaev@bk-internal.mysql.com:/home/bk/mysql-4.1 · 9c4d5e70
      unknown authored
      into  rurik.mysql.com:/home/igor/mysql-4.1
      
      9c4d5e70
    • unknown's avatar
      Merge aelkin@bk-internal.mysql.com:/home/bk/mysql-5.0 · b245f68e
      unknown authored
      into  mysql.com:/usr_rh9/home/elkin.rh9/MySQL/Merge/5.0-bug19136
      
      
      sql/sql_select.cc:
        Auto merged
      b245f68e
    • unknown's avatar
      Bug#19136: Crashing log-bin and uninitialized user variables in a derived table · a423451f
      unknown authored
      recalculating results
      
      
      mysql-test/r/rpl_user_variables.result:
        fixing results
      a423451f
    • unknown's avatar
    • unknown's avatar
      Merge mysql.com:/usr_rh9/home/elkin.rh9/4.1 · ddb829c0
      unknown authored
      into  mysql.com:/usr_rh9/home/elkin.rh9/MySQL/Merge/5.0-bug19136
      
      
      sql/item_func.cc:
        Auto merged
      sql/sql_select.cc:
        Auto merged
      mysql-test/r/rpl_user_variables.result:
        manual merge use local
      mysql-test/t/rpl_user_variables.test:
        manual merge use version 5.0's "show binlog events from 98"
      ddb829c0
    • unknown's avatar
      Merge mysql.com:/usr_rh9/home/elkin.rh9/MySQL/BARE/4.1 · 9bc4cc75
      unknown authored
      into  mysql.com:/usr_rh9/home/elkin.rh9/MySQL/FIXES/4.1-bug19136_unass_user_var
      
      
      sql/item_func.cc:
        Auto merged
      9bc4cc75
    • unknown's avatar
      Fixed bug #14927. · 39c73589
      unknown authored
      A query with a group by and having clauses could return a wrong
      result set if the having condition contained a constant conjunct 
      evaluated to FALSE.
      It happened because the pushdown condition for table with
      grouping columns lost its constant conjuncts.
      Pushdown conditions are always built by the function make_cond_for_table
      that ignores constant conjuncts. This is apparently not correct when
      constant false conjuncts are present.
      
      
      
      mysql-test/r/having.result:
        Added a test case for bug #14927.
      mysql-test/t/having.test:
        Added a test case for bug #14927.
      sql/sql_lex.cc:
        Fixed bug #14927.
        Initialized fields for having conditions in  st_select_lex::init_query().
      sql/sql_lex.h:
        Fixed bug #14927.
        Added a field to restore having condititions for execution in SP and PS.
      sql/sql_prepare.cc:
        Fixed bug #14927.
        Added code to restore havinf conditions for execution in SP and PS.
      sql/sql_select.cc:
        Fixed bug #14927.
        Performed evaluation of constant expressions in having clauses.
        If the having condition contains a constant conjunct that is always false
        an empty result set is returned after the optimization phase.
        In this case the corresponding EXPLAIN command now returns 
        "Impossible HAVING" in the last column.
      39c73589
  3. 06 May, 2006 14 commits
  4. 05 May, 2006 7 commits
  5. 04 May, 2006 8 commits