1. 26 Oct, 2011 3 commits
  2. 25 Oct, 2011 3 commits
    • Marko Mäkelä's avatar
      Fix results after Bug#12661768 fix. · e8d793f8
      Marko Mäkelä authored
      e8d793f8
    • Marko Mäkelä's avatar
      Bug#13002783 PARTIALLY UNINITIALIZED CASCADE UPDATE VECTOR · 013ba71d
      Marko Mäkelä authored
      In the ON UPDATE CASCADE clause of FOREIGN KEY constraints, the
      calculated update vector was not fully initialized. This bug was
      introduced in the InnoDB Plugin when implementing support for
      ROW_FORMAT=DYNAMIC.
      
      Additionally, the data type information was not initialized, but
      apparently it has never been needed in this case.  Nevertheless, it is
      not good programming practice to pass uninitialized values around.
      
      calc_row_difference(): Declare the update field uninitialized in
      Valgrind. Copy the data type information as well, except when the
      field is SQL NULL. In the built-in InnoDB, initialize
      ufield->extern_storage = FALSE (an initialization bug that had gone
      unnoticed this far). The InnoDB Plugin and later have this flag to
      dfield_t and have always initialized it properly.
      
      row_ins_cascade_calc_update_vec(): Reduce the scope of some
      pointers. Initialize orig_len. (This caused the bug in InnoDB Plugin
      and later.)
      
      row_ins_foreign_check_on_constraint(): Simplify a condition. Declare
      the update vector uninitialized.
      
      rb:771 approved by Jimmy Yang
      013ba71d
    • Vasil Dimov's avatar
      Fix Bug#12661768 UPDATE IGNORE CRASHES SERVER IF TABLE IS INNODB AND IT IS · dce33740
      Vasil Dimov authored
      PARENT FOR OTHER ONE
      
      Do not try to lookup key_nr'th key in 'table' because there may not be such
      a key there. key_nr is the number of the key in the _child_ table name, not
      in the parent table.
      
      Instead just print the fields of the record that are covered by the first key
      defined on the parent table.
      
      This bug gets a better fix in MySQL 5.6, which is too risky for 5.1 and 5.5.
      
      Approved by:	Jon Olav Hauglid (via IM)
      dce33740
  3. 24 Oct, 2011 2 commits
  4. 21 Oct, 2011 3 commits
  5. 20 Oct, 2011 2 commits
    • Alexander Nozdrin's avatar
    • Sergey Vojtovich's avatar
      BUG#11757032 - 49030: OPTIMIZE TABLE BREAKS MYISAM TABLE WHEN · de8c70e7
      Sergey Vojtovich authored
                     USING MYISAM_USE_MMAP ON WINDOWS
      
      When OPTIMIZE/REPAIR TABLE is switching to new data file,
      old data file is removed while memory mapping is still
      active.
      
      With 5.1 implementation of nt_share_delete() it is not
      permitted to remove mmaped file.
      
      This fix disables memory mapping for mi_repair() operations.
      
      mysql-test/r/myisam.result:
        A test case for BUG#11757032.
      mysql-test/t/myisam.test:
        A test case for BUG#11757032.
      storage/myisam/ha_myisam.cc:
        mi_repair*() functions family use file I/O even if memory
        mapping is available.
        
        Since mixing mmap I/O and file I/O may cause various artifacts,
        memory mapping must be disabled.
      storage/myisam/mi_delete_all.c:
        Clean-up: do not attempt to remap file after truncate, since
        there is nothing to map.
      de8c70e7
  6. 19 Oct, 2011 2 commits
  7. 18 Oct, 2011 1 commit
  8. 14 Oct, 2011 2 commits
    • Tor Didriksen's avatar
      merge 5.0-security => 5.1 security · 5dc553cd
      Tor Didriksen authored
      5dc553cd
    • Tor Didriksen's avatar
      Bug#12563865 ROUNDED,TMP_BUF,DECIMAL_VALUE STACK CORRUPTION IN ALL VERSIONS >=5.0 · a6145f4b
      Tor Didriksen authored
      Buffer over-run on all platforms, crash on windows, wrong result on other platforms,
      when rounding numbers which start with 999999999 and have
      precision = 9 or 18 or 27 or 36 ...
      
      
      mysql-test/r/type_newdecimal.result:
        New test cases.
      mysql-test/t/type_newdecimal.test:
        New test cases.
      sql/my_decimal.h:
        Add sanity checking code, to catch buffer over/under-run.
      strings/decimal.c:
        The original initialization of intg1 (add 1 if buf[0] == DIG_MAX)
        will set p1 to point outside the buffer, and the loop to copy the original value
            while (buf0 < p0)
              *(--p1) = *(--p0);
        will overwrite memory outside the my_decimal object.
      a6145f4b
  9. 13 Oct, 2011 1 commit
  10. 12 Oct, 2011 5 commits
    • Georgi Kodinov's avatar
    • Georgi Kodinov's avatar
      auto-merge mysql-5.1->mysql-5.1-security · 494b581f
      Georgi Kodinov authored
      494b581f
    • Georgi Kodinov's avatar
      auto-merge mysql-5.0->mysql-5.0-security · 98231daa
      Georgi Kodinov authored
      98231daa
    • Marko Mäkelä's avatar
      Bug#13006367 62487: innodb takes 3 minutes to clean up the adaptive · 6d590649
      Marko Mäkelä authored
      hash index at shutdown
      
      btr_search_disable(): Just drop the entire adaptive hash index,
      without dropping every record separately.
      
      buf_pool_clear_hash_index(): Renamed and simplified from
      buf_pool_drop_hash_index(). Set block->index = NULL for every block in
      the buffer pool. Do not release the btr_search_latch. The caller will
      have to adjust other data structures.
      
      Remove block->is_hashed. It is redundant, should be always equal to
      block->index != NULL.
      
      Remove btr_search_fully_disabled, btr_search_enabled_mutex, and
      SYNC_SEARCH_SYS_CONF. We drop the AHI in one pass, without releasing
      the btr_search_latch in between.
      
      Replace void* with const rec_t* and add assertions on btr_search_latch
      and btr_search_enabled to ha0ha.h, ha0ha.ic, ha0ha.c.
      
      page_set_max_trx_id(): Ignore the adaptive hash index. I forgot to
      push this in rb:750.
      
      btr0sea.c: Always after acquiring btr_search_latch, check for
      block->index==NULL or !btr_search_enabled. We can now set
      block->index=NULL while only holding btr_search_latch in exclusive
      mode. Always acquire btr_search_latch before reading block->index,
      except in shortcuts when testing for block->index == NULL.
      
      ha_clear(), ha_search(): Unused function, remove.
      
      buf_page_peek_if_search_hashed(): Remove. This function may avoid
      latching a page at the cost of doing a duplicate buf_pool->page_hash
      lookup.
      
      rb:775 approved by Inaam Rana
      6d590649
    • Vinay Fisrekar's avatar
      bug#11766457 - adjusting/modifying the the tests as tests were failing if... · 73db2a15
      Vinay Fisrekar authored
      bug#11766457 - adjusting/modifying the the tests as tests were failing if system time zone is set differently.
      73db2a15
  11. 10 Oct, 2011 1 commit
  12. 07 Oct, 2011 1 commit
    • Magne Mahre's avatar
      BUG#12589870 CRASHES WITH MULTIQUERY PACKET + USE<DB> + QUERY CACHE · f36e854a
      Magne Mahre authored
       
      A buffer large enough to hold the query _plus_ some additional
      data is allocated before parsing is started.   The additional data 
      is used by the query cache, and consists of the name of the current 
      database and a set of flags.
       
      When a packet containing multiple SQL statements is sent to the
      server and one of the statements changes the current database
      (a "USE <db>" statement), and the name of the new current database 
      is longer than of the previous,  there is not enough space in the 
      buffer for the new name, and we write out over the buffer boundary.
      
      The fix adds an extra field to store the number of bytes
      allocated to the database name in the buffer.  If the current
      database name changes, and the new name is longer than the
      previous one, we refuse to cache the query.
      f36e854a
  13. 06 Oct, 2011 2 commits
  14. 05 Oct, 2011 4 commits
    • Bjorn Munch's avatar
      merge 5.1-mtr => 5.1 · b84202db
      Bjorn Munch authored
      b84202db
    • Sergey Glukhov's avatar
      automerge · 44145ce6
      Sergey Glukhov authored
      44145ce6
    • Sergey Glukhov's avatar
      Bug#11747970 34660: CRASH WHEN FEDERATED TABLE LOSES CONNECTION DURING INSERT ... SELECT · 14dc91ff
      Sergey Glukhov authored
      Problematic query:
      insert ignore into `t1_federated` (`c1`) select `c1` from  `t1_local` a
      where not exists (select 1 from `t1_federated` b where a.c1 = b.c1);
      When this query is killed in another connection it could lead to crash.
      The problem is follwing:
      An attempt to obtain table statistics for subselect table in killed query
      fails with an error. So JOIN::optimize() for subquery is failed but
      it does not prevent further subquery evaluation.
      At the first subquery execution JOIN::optimize() is called
      (see subselect_single_select_engine::exec()) and fails with
      an error. 'executed' flag is set to TRUE and it prevents
      further subquery evaluation. At the second call
      JOIN::optimize() does not happen as 'JOIN::optimized' is TRUE
      and in case of uncacheable subquery the 'executed' flag is set
      to FALSE before subquery evaluation. So we loose 'optimize stage'
      error indication (see subselect_single_select_engine::exec()).
      In other words 'executed' flag is used for two purposes, for
      error indication at JOIN::optimize() stage and for an
      indication of subquery execution. And it seems it's wrong
      as the flag could be reset.
      
      
      mysql-test/r/error_simulation.result:
        test case
      mysql-test/t/error_simulation.test:
        test case
      sql/item_subselect.cc:
        added new flag subselect_single_select_engine::optimize_error
        which is used for error detection which could happen at optimize
        stage.
      sql/item_subselect.h:
        added new flag subselect_single_select_engine::optimize_error
      sql/sql_select.cc:
        test case
      14dc91ff
    • Marko Mäkelä's avatar
      Add InnoDB UNIV_SYNC_DEBUG assertions to rw-lock code. · 16c91952
      Marko Mäkelä authored
      rw_lock_x_lock_func(): Assert that the thread is not already holding
      the lock in a conflicting mode (RW_LOCK_SHARED).
      
      rw_lock_s_lock_func(): Assert that the thread is not already holding
      the lock in a conflicting mode (RW_LOCK_EX).
      16c91952
  15. 04 Oct, 2011 5 commits
  16. 03 Oct, 2011 1 commit
  17. 29 Sep, 2011 2 commits
    • Tatjana Azundris Nuernberg's avatar
      manual merge · 7944320f
      Tatjana Azundris Nuernberg authored
      7944320f
    • Tatjana Azundris Nuernberg's avatar
      Bug#11765687 (MySQL58677): No privilege on table / view, but can know #rows /... · 8932ae21
      Tatjana Azundris Nuernberg authored
      Bug#11765687 (MySQL58677): No privilege on table / view, but can know #rows / underlying table's name
      
      1 - If a user had SHOW VIEW and SELECT privileges on a view and
      this view was referencing another view, EXPLAIN SELECT on the outer
      view (that the user had privileges on) could reveal the structure
      of the underlying "inner" view as well as the number of rows in
      the underlying tables, even if the user had privileges on none of
      these referenced objects.
      
      This happened because we used DEFINER's UID ("SUID") not just for
      the view given in EXPLAIN, but also when checking privileges on
      the underlying views (where we should use the UID of the EXPLAIN's
      INVOKER instead).
      
      We no longer run the EXPLAIN SUID (with DEFINER's privileges).
      This prevents a possible exploit and makes permissions more
      orthogonal.
      
      2 - EXPLAIN SELECT would reveal a view's structure even if the user
      did not have SHOW VIEW privileges for that view, as long as they
      had SELECT privilege on the underlying tables.
      
      Instead of requiring both SHOW VIEW privilege on a view and SELECT
      privilege on all underlying tables, we were checking for presence
      of either of them.
      
      We now explicitly require SHOW VIEW and SELECT privileges on
      the view we run EXPLAIN SELECT on, as well as all its
      underlying views. We also require SELECT on all relevant
      tables. 
      
      
      mysql-test/r/view_grant.result:
        add extensive tests to illustrate desired behavior and
        prevent regressions (as always).
      mysql-test/t/view_grant.test:
        add extensive tests to illustrate desired behavior and
        prevent regressions (as always).
      sql/sql_view.cc:
        We no longer run the EXPLAIN SUID (with DEFINER's privileges).
        To achieve this, we use a temporary, SUID-less TABLE_LIST for
        the views while checking privileges.
      8932ae21