1. 10 Apr, 2012 1 commit
  2. 09 Apr, 2012 1 commit
  3. 06 Apr, 2012 2 commits
    • Mayank Prasad's avatar
      BUG#13738989 : 62136 : FAILED TO FETCH SELECT RESULT USING EMBEDDED MYSQLD · fe3f7993
      Mayank Prasad authored
      Background : 
      In mysql-5.1, in a fix for bug#47485, code has been changed for 
      mysql client (libmysql/libmysql.c) but corresponding code was not
      changed for embedded mysql. In that code change, after execution
      of a statement, mysql_stmt_store_result() checks for mysql->state
      to be MYSQL_STATUS_STATEMENT_GET_RESULT, instead of
      MYSQL_STATUS_GET_RESULT (earlier).
      
      Reason:
      In embedded mysql code, after execution, mysql->state was not
      set to MYSQL_STATUS_STATEMENT_GET_RESULT, so it was throwing
      OUT_OF_SYNC error.
      
      Fix:
      Fixed the code in libmysqld/lib_sql.cc to have mysql->state
      to be set to MYSQL_STATUS_STATEMENT_GET_RESULT after execution.
      
      fe3f7993
    • Georgi Kodinov's avatar
      Bug #13934049: 64884: LOGINS WITH INCORRECT PASSWORD ARE ALLOWED · 7dcf0a66
      Georgi Kodinov authored
      Fixed an improper type conversion on return that can make the server accept
      logins with a wrong password.
      7dcf0a66
  4. 04 Apr, 2012 1 commit
    • Sergey Glukhov's avatar
      Bug#11766300 59387: FAILING ASSERTION: CURSOR->POS_STATE == 1997660512 (BTR_PCUR_IS_POSITIONE · b5c690aa
      Sergey Glukhov authored
      Bug#13639204 64111: CRASH ON SELECT SUBQUERY WITH NON UNIQUE INDEX
      The crash happened due to wrong calculation
      of key length during creation of reference for
      sort order index. The problem is that
      keyuse->used_tables can have OUTER_REF_TABLE_BIT enabled
      but used_tables parameter(create_ref_for_key() func) does
      not have it. So key parts which have OUTER_REF_TABLE_BIT
      are ommited and it could lead to incorrect key length
      calculation(zero key length).
      
      
      mysql-test/r/subselect_innodb.result:
        test result
      mysql-test/t/subselect_innodb.test:
        test case
      sql/sql_select.cc:
        added OUTER_REF_TABLE_BIT to the used_tables parameter
        for create_ref_for_key() function.
      storage/innobase/handler/ha_innodb.cc:
        added assertion, request from Inno team
      storage/innodb_plugin/handler/ha_innodb.cc:
        added assertion, request from Inno team
      b5c690aa
  5. 28 Mar, 2012 3 commits
    • Praveenkumar Hulakund's avatar
      Bug#11763507 - 56224: FUNCTION NAME IS CASE-SENSITIVE · f3d5127f
      Praveenkumar Hulakund authored
      Analysis:
      -------------------------------
      According to the Manual
      (http://dev.mysql.com/doc/refman/5.1/en/identifier-case-sensitivity.html):
      "Column, index, stored routine, and event names are not case sensitive on any
      platform, nor are column aliases."
      
      In other words, 'lower_case_table_names' does not affect the behaviour of 
      those identifiers.
      
      On the other hand, trigger names are case sensitive on some platforms,
      and case insensitive on others. 'lower_case_table_names' does not affect
      the behaviour of trigger names either.
      
      The bug was that SHOW statements did case sensitive comparison
      for stored procedure / stored function / event names.
      
      Fix:
      Modified the code so that comparison in case insensitive for routines 
      and events for "SHOW" operation.
      
      As part of this commit, only fixing the test failures due to the actual code fix.
      f3d5127f
    • Sunny Bains's avatar
      Merge from mysql-5.0 · 83a5a20d
      Sunny Bains authored
      83a5a20d
    • Sunny Bains's avatar
      Bug# 13847885 - PURGING STALLS WHEN PURGE_SYS->N_PAGES_HANDLED OVERFLOWS · 65126ffa
      Sunny Bains authored
      Change the type of purge_sys_t::n_pages_handled and purge_sys_t::handle_limit
      to ulonglong from ulint. On a 32 bit system doing ~700 deletes per second the
      counters can overflow in ~3.5 months, if they are 32 bit.
      
      Approved by Jimmy Yang over IM.
      65126ffa
  6. 27 Mar, 2012 2 commits
  7. 21 Mar, 2012 4 commits
  8. 20 Mar, 2012 2 commits
  9. 16 Mar, 2012 1 commit
  10. 15 Mar, 2012 3 commits
    • Inaam Rana's avatar
      Bug#13825266 RACE IN LOCK_VALIDATE() WHEN ACCESSING PAGES DIRECTLY · 00231470
      Inaam Rana authored
      FROM BUFFER POOL
      
      rb://975
      approved by: Marko Makela
      
      There is a race in lock_validate() where we try to access a page
      without ensuring that the tablespace stays valid during the operation
      i.e.: it is not deleted. This patch tries to fix that by using an
      existing flag (the flag is renamed to make it's name more generic
      in line with it's new use).
      00231470
    • Inaam Rana's avatar
      Bug#13851171 STRING OVERFLOW IN INNODB CODE FOUND BY STATIC ANALYSIS · 04c96834
      Inaam Rana authored
      rb://976
      approved by: Marko Makela
      
      Add an assertion to ensure that string overflow is not happening.
      Pointed by Coverity analysis.
      04c96834
    • Inaam Rana's avatar
      Bug#13537504 VALGRIND: COND. JUMP/MOVE DEPENDS ON UNINITIALISED VALUES · a8217b7c
      Inaam Rana authored
      IN OS_THREAD_EQ
      
      rb://977
      approved by: Marko Makela
      
      rw_lock::writer_thread field contains the thread id of current x-holder
      or wait-x thread. This field is un-initialized at lock creation and is
      written to for the first time when an attempt is made to x-lock.
      
      Current code considers ::writer_thread as valid memory region only when
      the lock is held in x-mode (or there is an x-waiter). This is an
      overkill and it generates valgrind warnings.
      
      The fix is to consider ::writer_thread as valid memory region once it
      has been written to.
      
      Reasoning:
      ==========
      The ::writer_thread can be safely considered valid because:
      
      * We only ever do comparison with current calling threads id.
      * We only ever do comparison when ::recursive flag is set
      * We always unset ::recursive flag in x-unlock
      * Same thread cannot be unlocking and attempting to lock at the same
      time
      * thread_id recycling is not an issue because before an id is recycled
      the thread must leave innodb meaning it must release all locks meaning
      it must unset ::recursive flag.
      a8217b7c
  11. 12 Mar, 2012 6 commits
    • Luis Soares's avatar
      BUG#12400313 · 7f84e70b
      Luis Soares authored
      Adding missing sync_slave_with_master to the test case.
      7f84e70b
    • Luis Soares's avatar
      Automerge merge with latest mysql-5.1. · a68e3d26
      Luis Soares authored
      a68e3d26
    • Luis Soares's avatar
      BUG#12400313 · 9eedf9b4
      Luis Soares authored
      Hardening the test case:
        - including a diff_tables at the end.
        - increasing the tolerance on the relay limit size.
      9eedf9b4
    • Luis Soares's avatar
      BUG#12400313 · 28e71956
      Luis Soares authored
      Automerge with mysql-5.1.
      28e71956
    • Luis Soares's avatar
      BUG#12400313 RELAY_LOG_SPACE_LIMIT IS NOT WORKING IN MANY CASES · 4a6c4d86
      Luis Soares authored
      BUG#64503: mysql frequently ignores --relay-log-space-limit
      
      When the SQL thread goes to sleep, waiting for more events, it sets
      the flag ignore_log_space_limit to true. This gives the IO thread a
      chance to queue some more events and ultimately the SQL thread will be
      able to purge the log once it is rotated. By then the SQL thread
      resets the ignore_log_space_limit to false. However, between the time
      the SQL thread has set the ignore flag and the time it resets it, the
      IO thread will be queuing events in the relay log, possibly going way
      over the limit.
      
      This patch makes the IO and SQL thread to synchronize when they reach
      the space limit and only ask for one event at a time. Thus the SQL
      thread sets ignore_log_space_limit flag and the IO thread resets it to
      false everytime it processes one more event. In addition, everytime
      the SQL thread processes the next event, and the limit has been
      reached, it checks if the IO thread should rotate. If it should, it
      instructs the IO thread to rotate, giving the SQL thread a chance to
      purge the logs (freeing space). Finally, this patch removes the
      resetting of the ignore_log_space_limit flag from purge_first_log,
      because this is now reset by the IO thread every time it processes the
      next event when the limit has been reached.
      
      If the SQL thread is in a transaction, it cannot purge so, there is no
      point in asking the IO thread to rotate. The only thing it can do is
      to ask for more events until the transaction is over (then it can ask
      the IO to rotate and purge the log right away). Otherwise, there would
      be a deadlock (SQL would not be able to purge and IO thread would not
      be able to queue events so that the SQL would finish the transaction).
      4a6c4d86
    • Norvald H. Ryeng's avatar
      Bug#13031606 VALUES() IN A SELECT STATEMENT CRASHES SERVER · ad031d51
      Norvald H. Ryeng authored
      Problem: Grouping results by VALUES(alias for string literal) causes
      the server to crash.
      
      Item_insert_values is not constructed to handle other types of
      arguments than field and reference to field. In this case, the
      argument is an Item_string, and this causes
      Item_insert_values::fix_fields() to crash.
      
      Fix: Issue an error message when the argument to Item_insert_values is
      not a field or a reference to a field.
      
      This is slightly in breach with documentation, which states that
      VALUES should return NULL, but the error message is only issued in
      cases where the server otherwise would crash, so there is no change in
      behavior for queries that already work. Future versions will restrict
      syntax so that using VALUES in this way is illegal.
      
      
      mysql-test/r/errors.result:
        Add test case for bug #13031606.
      mysql-test/t/errors.test:
        Add test case for bug #13031606.
      sql/item.cc:
        Issue error message if argument is not field or reference to field.
      ad031d51
  12. 11 Mar, 2012 1 commit
  13. 09 Mar, 2012 1 commit
  14. 08 Mar, 2012 5 commits
    • Georgi Kodinov's avatar
    • Georgi Kodinov's avatar
      merge mysql-5.1->mysql-5.1-security · 4b5306fd
      Georgi Kodinov authored
      4b5306fd
    • Georgi Kodinov's avatar
      7ac4179e
    • Marko Mäkelä's avatar
    • Marko Mäkelä's avatar
      Bug#13807811 BTR_PCUR_RESTORE_POSITION() CAN SKIP A RECORD · c5511bdf
      Marko Mäkelä authored
      This bug has been there at least since MySQL 4.0.9. (Before 4.0.9, the
      code probably was even more severely broken.)
      
      btr_pcur_restore_position(): When cursor restoration fails, before
      invoking btr_pcur_store_position() move to the previous or next record
      unless cursor->rel_pos==BTR_PCUR_ON or the record was not a user
      record.
      
      This bug can cause skipped records when btr_pcur_store_position() is
      called on the last record of a page. A symptom would be record count
      mismatch in CHECK TABLE, or failure to find a record to delete-mark or
      update or purge. The following operations should be affected by the
      bug:
      
      * row_search_for_mysql(): SELECT, UPDATE, REPLACE, CHECK TABLE,
        (almost anything else than INSERT)
      
      * foreign key CASCADE operations
      
      * row_merge_read_clustered_index(): index creation (since MySQL 5.1
        InnoDB Plugin)
      
      * multi-threaded purge (after MySQL 5.5): not sure, but it might fail
        to purge some records
      
      Not all callers of btr_pcur_restore_position() should be affected.
      Anything that asserts or checks that restoration succeeds is
      unaffected. For example, cursor restoration on the change buffer tree
      should always succeed, because access is being protected by additional
      latches. Likewise, rollback, or any code accesses data dictionary
      tables while holding dict_sys->mutex should be safe.
      
      rb:967 approved by Jimmy Yang
      c5511bdf
  15. 06 Mar, 2012 2 commits
  16. 05 Mar, 2012 2 commits
    • Ramil Kalimullin's avatar
      BUG#12537203 - CRASH WHEN SUBSELECTING GLOBAL VARIABLES IN GEOMETRY FUNCTION ARGUMENTS · 30d32207
      Ramil Kalimullin authored
      A defect in the subquery substitution code may lead to a server crash:
      setting substitution's name should be followed by setting its length
      (to keep them in sync).
      
      
      mysql-test/r/gis.result:
        BUG#12537203 - CRASH WHEN SUBSELECTING GLOBAL VARIABLES IN GEOMETRY FUNCTION ARGUMENTS
          test result.
      mysql-test/t/gis.test:
        BUG#12537203 - CRASH WHEN SUBSELECTING GLOBAL VARIABLES IN GEOMETRY FUNCTION ARGUMENTS
          test case.
      sql/item_subselect.cc:
        BUG#12537203 - CRASH WHEN SUBSELECTING GLOBAL VARIABLES IN GEOMETRY FUNCTION ARGUMENTS
          set substitution's name length as well as the name itself (to keep them in sync).
      30d32207
    • Ramil Kalimullin's avatar
      Fix for BUG#12414917 - ISCLOSED() CRASHES ON 64-BIT BUILDS · 8aea62fa
      Ramil Kalimullin authored
      Problem:      
      lack of incoming geometry data validation may 
      lead to a server crash when ISCLOSED() function called.
      
      Solution:
      necessary incoming data check added.
      
      
      mysql-test/r/gis.result:
        Fix for BUG#12414917 - ISCLOSED() CRASHES ON 64-BIT BUILDS
          test result.
      mysql-test/t/gis.test:
        Fix for BUG#12414917 - ISCLOSED() CRASHES ON 64-BIT BUILDS 
          test case.
      sql/spatial.cc:
        Fix for BUG#12414917 - ISCLOSED() CRASHES ON 64-BIT BUILDS 
          check if a LINESTRING has at least one point as we 
        rely on that further.
      8aea62fa
  17. 02 Mar, 2012 2 commits
  18. 01 Mar, 2012 1 commit