1. 09 Jan, 2012 2 commits
    • Jon Olav Hauglid's avatar
      Merge from mysql-5.1-security to mysql-5.5-security · 95d56d0e
      Jon Olav Hauglid authored
      Text conflict in sql/sql_yacc.yy
      95d56d0e
    • Jon Olav Hauglid's avatar
      Backport from mysql-trunk of: · a66b452d
      Jon Olav Hauglid authored
      ------------------------------------------------------------
      revno: 3258
      committer: Jon Olav Hauglid <jon.hauglid@oracle.com>
      branch nick: mysql-trunk-bug12663165
      timestamp: Thu 2011-07-14 10:05:12 +0200
      message:
        Bug#12663165 SP DEAD CODE REMOVAL DOESN'T UNDERSTAND CONTINUE HANDLERS
        
        When stored routines are loaded, a simple optimizer tries to locate
        and remove dead code. The problem was that this dead code removal
        did not work correctly with CONTINUE handlers.
        
        If a statement triggers a CONTINUE handler, the following statement
        will be executed after the handler statement has completed. This
        means that the following statement is not dead code even if the
        previous statement unconditionally alters control flow. This fact
        was lost on the dead code removal routine, which ended up with
        removing instructions that could have been executed. This could
        then lead to assertions, crashes and generally bad behavior when
        the stored routine was executed.
        
        This patch fixes the problem by marking as live code all stored
        routine instructions that are in the same scope as a CONTINUE handler.
        
        Test case added to sp.test.
      a66b452d
  2. 22 Dec, 2011 2 commits
    • Vasil Dimov's avatar
      9208e8d7
    • Vasil Dimov's avatar
      Fix Bug#13510739 63775: SERVER CRASH ON HANDLER READ NEXT AFTER DELETE RECORD. · 41f309dd
      Vasil Dimov authored
      CREATE TABLE bug13510739 (c INTEGER NOT NULL, PRIMARY KEY (c)) ENGINE=INNODB;
      INSERT INTO bug13510739 VALUES (1), (2), (3), (4);
      DELETE FROM bug13510739 WHERE c=2;
      HANDLER bug13510739 OPEN;
      HANDLER bug13510739 READ `primary` = (2);
      HANDLER bug13510739 READ `primary` NEXT;  <-- crash
      
      The bug is that in the particular testcase row_search_for_mysql() picked up
      a delete-marked record and quit, leaving the cursor non-positioned state and
      on the subsequent 'get next' call the code crashed because of the
      non-positioned cursor.
      
      In row0sel.cc (line numbers from mysql-trunk):
      
      4653         if (rec_get_deleted_flag(rec, comp)) {
      ...
      4679                 if (index == clust_index && unique_search) {
      4680 
      4681                         err = DB_RECORD_NOT_FOUND;
      4682                         
      4683                         goto normal_return;
      4684                 }       
      
      it quit from here, not storing the cursor position.
      
      In contrast, if the record=2 is not found at all (e.g. sleep(1) after DELETE
      to let the purge wipe it away completely) then 'get = 2' does find record=3
      and quits from here:
      
      4366                 if (0 != cmp_dtuple_rec(search_tuple, rec, offsets)) {
      ...
      4394                         btr_pcur_store_position(pcur, &mtr);
      4395 
      4396                         err = DB_RECORD_NOT_FOUND;
      4397 #if 0
      4398                         ut_print_name(stderr, trx, FALSE, index->name);
      4399                         fputs(" record not found 3\n", stderr);
      4400 #endif
      4401 
      4402                         goto normal_return;
      
      Another fix could be to extend the condition on line 4366 to hold only if
      seach_tuple matches rec AND if rec is not delete marked.
      
      Notice that in the above test case if we wait about 1 second somewhere after
      DELETE and before 'get = 2', then the testcase does not crash and returns 4
      instead. Not sure if this is the correct behavior, but this bugfix removes
      the crash and makes the code return what it also returns in the non-crashing
      case (if rec=2 is not found during 'get = 2', e.g. we have sleep(1) there).
      
      Approved by:	Marko (http://bur03.no.oracle.com/rb/r/863/)
      41f309dd
  3. 16 Dec, 2011 13 commits
  4. 15 Dec, 2011 7 commits
  5. 14 Dec, 2011 6 commits
    • Andrei Elkin's avatar
      · 55e5f7a4
      Andrei Elkin authored
      bug#13437900
      post-push changes to please solaris compiler.
      55e5f7a4
    • Mattias Jonsson's avatar
      merged bug#12361113. · 5fcdf63f
      Mattias Jonsson authored
      Also added tests for partitions key caches.
      5fcdf63f
    • Mattias Jonsson's avatar
      merge · c2f80e50
      Mattias Jonsson authored
      c2f80e50
    • Andrei Elkin's avatar
      Bug#13437900 - VALGRIND REPORTS A LEAK FOR REPL_IGNORE_SERVER_IDS · 3d10b244
      Andrei Elkin authored
      There was memory leak when running some tests on PB2.
      The reason of the failure is an early return from change_master()
      that was supposed to deallocate a dyn-array.
      
      Actually the same bug58915 was fixed in trunk with relocating the dyn-array
      destruction into THD::cleanup_after_query() which can't be bypassed.
      The current patch backports magne.mahre@oracle.com-20110203101306-q8auashb3d7icxho
      and adds two optimizations: were done: the static buffer for the dyn-array to base on,
      and the array initialization is called precisely when it's necessary rather than
      per each CHANGE-MASTER as before.
      
      
      mysql-test/suite/rpl/t/rpl_empty_master_host.test:
        the test is binlog-format insensitive so it will be run with MIXED mode only.
      mysql-test/suite/rpl/t/rpl_server_id_ignore.test:
        the test is binlog-format insensitive so it will be run with MIXED mode only.
      sql/sql_class.cc:
        relocating the dyn-array
        destruction into THD::cleanup_after_query().
      sql/sql_lex.cc:
        LEX.mi zero initialization is done in LEX().
      sql/sql_lex.h:
        Optimization for repl_ignore_server_ids to base on a static buffer
        which size is chosen to fit to most common use cases.
      sql/sql_repl.cc:
        dyn-array destruction is relocated to THD::cleanup_after_query().
      sql/sql_yacc.yy:
        Refining logics of Lex->mi.repl_ignore_server_ids initialization.
        The array is initialized once a corresponding option in CHANGE MASTER token sequence
        is found.
      3d10b244
    • Mattias Jonsson's avatar
      merge · f898c046
      Mattias Jonsson authored
      f898c046
    • Georgi Kodinov's avatar
      Addendum to the fix for bug #11754011: fixed a testcase result to include · f834e73b
      Georgi Kodinov authored
      the new --slow-start-timeout option's help output
      f834e73b
  6. 13 Dec, 2011 3 commits
    • Georgi Kodinov's avatar
      Bug#11754011: 45546: START WINDOWS SERVICE, THEN EXECUTE WHAT IS NEEDED. · 99acacba
      Georgi Kodinov authored
      Added a global read-only option slow-start-timeout to control the
      Windows service control manager's service start timeout, that was
      currently hard-coded to be 15 seconds.
      The default of the new option is 15 seconds.
      The timeout can also be set to 0 (to mean no timeout applicable).
      99acacba
    • Annamalai Gurusami's avatar
      20caab8c
    • Annamalai Gurusami's avatar
      Bug #13117023: Innodb increments handler_read_key when it should not · f080e98e
      Annamalai Gurusami authored
      The counter handler_read_key (SSV::ha_read_key_count) is incremented 
      incorrectly.
      
      The mysql server maintains a per thread system_status_var (SSV)
      object.  This object contains among other things the counter
      SSV::ha_read_key_count. The purpose of this counter is to measure the
      number of requests to read a row based on a key (or the number of
      index lookups).
      
      This counter was wrongly incremented in the
      ha_innobase::innobase_get_index(). The fix removes
      this increment statement (for both innodb and innodb_plugin).
      
      The various callers of the innobase_get_index() was checked to
      determine if anybody must increment this counter (if they first call
      innobase_get_index() and then perform an index lookup).  It was found
      that no caller of innobase_get_index() needs to worry about the
      SSV::ha_read_key_count counter.
      f080e98e
  7. 12 Dec, 2011 6 commits
  8. 08 Dec, 2011 1 commit
    • unknown's avatar
      Bug #13116225 LIVE DOWNGRADE CRASHES WITH INNODB_PAGE_SIZE=4K · 8e198589
      unknown authored
      This bug ensures that a live downgrade from an InnoDB 5.6 with WL5756 and
      a database created with innodb-page-size=8k or 4k will make a version 5.5
      installation politely refuse to start. Instead of crashing or giving some
      indication about a corrupted database, it will indicate the page size
      difference. 
      
      This patch takes only that part of the Wl5756 patch that is needed to
      protect against opening a tablespace that is stamped with a different
      page size.
      
      It also contains the change in dict_index_find_on_id_low() just in case
      a database with another page size is created by recompiling a pre-WL5756
      InnoDB.
      8e198589