1. 29 Jun, 2011 4 commits
  2. 28 Jun, 2011 1 commit
    • Marko Mäkelä's avatar
      Bug#12595087 - 61191: Question about page_zip_available (clean up page0zip.c) · 0c54d44f
      Marko Mäkelä authored
      page_zip_dir_elems(): New function, refactored from page_zip_dir_size().
      
      page_zip_dir_size(): Use page_zip_dir_elems()
      
      page_zip_dir_start_offs(): New function: Gets an offset to the
      compressed page trailer (the dense page directory), including deleted
      records (the free list)
      
      page_zip_dir_start_low(page_zip, n_dense): Constness-preserving
      wrapper macro for page_zip_dir_start_offs().
      
      page_zip_dir_start(page_zip): Constness-preserving
      wrapper macro for page_zip_dir_start_offs().
      
      page_zip_decompress_node_ptrs(), page_zip_decompress_clust(): Replace
      a formula with a fully equivalent page_zip_dir_start_low() call.
      
      page_zip_write_rec(), page_zip_parse_write_node_ptr(),
      page_zip_write_node_ptr(), page_zip_write_trx_id_and_roll_ptr(),
      page_zip_clear_rec(): Replace a formula with an almost equivalent
      page_zip_dir_start() call.
      It is OK to replace page_dir_get_n_heap(page) with
      page_dir_get_n_heap(page_zip->data), because
      ut_ad(page_zip_header_cmp(page_zip, page)) or
      page_zip_validate(page_zip, page) asserts that the
      page headers are identical.
      
      rb:687 approved by Jimmy Yang
      0c54d44f
  3. 23 Jun, 2011 1 commit
    • Dmitry Shulga's avatar
      Fixed Bug#11756013 (formerly known as bug#47870): · bc7af175
      Dmitry Shulga authored
      BOGUS "THE TABLE MYSQL.PROC IS MISSING,..."
      
      There was a race condition between loading a stored routine
      (function/procedure/trigger) specified by fully qualified name
      SCHEMA_NAME.PROC_NAME and dropping the stored routine database.
      
      The problem was that there is a window for race condition when one server
      thread tries to load a stored routine being executed and the other thread
      tries to drop the stored routine schema.
      
      This condition race window exists in implementation of function
      mysql_change_db() called by db_load_routine() during loading of stored
      routine to cache. Function mysql_change_db() calls check_db_dir_existence()
      that might failed because specified database was dropped during concurrent
      execution of DROP SCHEMA statement. db_load_routine() calls mysql_change_db()
      with flag 'force_switch' set to 'true' value so when referenced db is not found
      then my_error() is not called and function mysql_change_db() returns ok.
      This shadows information about schema opening error in db_load_routine().
      Then db_load_routine() makes attempt to parse stored routine that is failed.
      This makes to return error to sp_cache_routines_and_add_tables_aux() but since
      during error generation a call to my_error wasn't made and hence
      THD::main_da wasn't set we set the generic "mysql.proc table corrupt" error
      when running sp_cache_routines_and_add_tables_aux().
      
      The fix is to install an error handler inside db_load_routine() for
      the mysql_op_change_db() call, and check later if the ER_BAD_DB_ERROR
      was caught.
      
      
      sql/sql_db.cc:
        Added synchronization point "before_db_dir_check" to emulate a race condition during
        processing of CALL/DROP SCHEMA.
      bc7af175
  4. 17 Jun, 2011 2 commits
    • Inaam Rana's avatar
      Bug 12635227 - 61188: DROP TABLE EXTREMELY SLOW · e60e6505
      Inaam Rana authored
      approved by: Marko
      rb://681
      
      Coalescing of free buf_page_t descriptors can prove to be one severe
      bottleneck in performance of compression. One such workload where it
      hurts badly is DROP TABLE. This patch removes buf_page_t allocations
      from buf_buddy and uses ut_malloc instead.
      In order to further reduce overhead of colaescing we no longer attempt
      to coalesce a block if the corresponding free_list is less than 16 in
      size.
      e60e6505
    • Jon Olav Hauglid's avatar
      Bug#12657095 YASSL ERROR MESSAGE CONTAINS TYPO · 7de029da
      Jon Olav Hauglid authored
      This patch fixes a typo in a YaSSL error message.
      7de029da
  5. 16 Jun, 2011 6 commits
    • Dmitry Lenev's avatar
      Fix for bug #12652385 - "61493: REORDERING COLUMNS · edfd31a0
      Dmitry Lenev authored
      TO POSITION FIRST CAN CAUSE DATA TO BE CORRUPTED".
       
      ALTER TABLE MODIFY/CHANGE ... FIRST did nothing except renaming
      columns if new version of the table had exactly the same 
      structure as the old one (i.e. as result of such statement, names 
      of columns changed their order as specified but data in columns 
      didn't). The same thing happened for ALTER TABLE DROP COLUMN/ADD 
      COLUMN statements which were supposed to produce new version of
      table with exactly the same structure as the old version of table.
      I.e. in the latter case the result was the same as if old column 
      was renamed instead of being dropped and new column with default
      as value being created.
       
      Both these problems were caused by the fact that ALTER TABLE
      implementation incorrectly interpreted both these situations as 
      simple renaming of columns and assumed that in-place ALTER TABLE
      algorithm could have been used for them.
       
      This patch fixes this problem by ensuring that in cases when some
      column is moved to the first position or some column is dropped
      the default ALTER TABLE algorithm involving table copying is 
      always used. This is achieved by detecting such situations in
      mysql_prepare_alter_table() and setting Alter_info::change_level
      to ALTER_TABLE_DATA_CHANGED for them.
      
      mysql-test/r/alter_table.result:
        Added test for bug #12652385 - "61493: REORDERING COLUMNS TO
        POSITION FIRST CAN CAUSE DATA TO BE CORRUPTED".
      mysql-test/t/alter_table.test:
        Added test for bug #12652385 - "61493: REORDERING COLUMNS TO
        POSITION FIRST CAN CAUSE DATA TO BE CORRUPTED".
      sql/sql_table.cc:
        Changed mysql_prepare_alter_table() to detect situations in 
        which we some column moved to the first position or some column 
        is dropped and ensure that such ALTER TABLE statements won't
        be carried out using in-place algorithm. The latter could have 
        happened before this patch if new version of table had the same 
        structure as the old one (except the column names).
      edfd31a0
    • Vasil Dimov's avatar
      Silence bogus compiler warning introduced in · 0dfe86f5
      Vasil Dimov authored
      marko.makela@oracle.com-20110616072721-8bo92ctixq6eqavr
      0dfe86f5
    • Marko Mäkelä's avatar
      Bug #61341 buf_LRU_insert_zip_clean can be O(N) on LRU length · b0fc27dc
      Marko Mäkelä authored
      The buf_pool->zip_clean list is only needed for debugging, or for
      recomputing buf_pool->page_hash when resizing the buffer pool. Buffer
      pool resizing was never fully implemented. Remove the resizing code,
      and define buf_pool->zip_clean only in debug builds.
      
      buf_pool->zip_clean, buf_LRU_insert_zip_clean(): Enclose in
      #if defined UNIV_DEBUG || UNIV_BUF_DEBUG.
      
      buf_chunk_free(), buf_chunk_all_free(), buf_pool_shrink(),
      buf_pool_page_hash_rebuild(), buf_pool_resize(): Remove (unreachable code).
      
      rb:671 approved by Inaam Rana
      b0fc27dc
    • Marko Mäkelä's avatar
      Bug#12595087 - 61191: Question about page_zip_available · e4aa6667
      Marko Mäkelä authored
      There is an apparent problem with page_zip_clear_rec().
      In btr_cur_optimistic_update() we do this:
      
      	page_cur_delete_rec(page_cursor, index, offsets, mtr);
      ...
      	rec = btr_cur_insert_if_possible(cursor, new_entry, 0/*n_ext*/, mtr);
      	ut_a(rec); /* <- We calculated above the insert would fit */
      
      The problem is that page_cur_delete_rec() could fill the modification
      log while doing page_zip_clear_rec(), requiring recompression for the
      btr_cur_insert_if_possible(). In a pathological case, the data could
      fail to recompress.
      
      page_zip_clear_rec(): Leave the page modification log alone. Only
      clear the necessary fields.
      
      rb:673 approved by Jimmy Yang
      e4aa6667
    • Marko Mäkelä's avatar
      Re-enable the debug assertions for Bug#12650861. · 417a2679
      Marko Mäkelä authored
      Replace UNIV_BLOB_NULL_DEBUG with UNIV_DEBUG||UNIV_BLOB_LIGHT_DEBUG. 
      Fix known bogus failures.
      
      btr_cur_optimistic_update(): If rec_offs_any_null_extern(), assert that
      the current transaction is an incomplete transaction that is being
      rolled back in crash recovery.
      
      row_build(): If rec_offs_any_null_extern(), assert that the transaction
      that last updated the record was recovered during crash recovery
      (and will soon be rolled back).
      417a2679
    • Marko Mäkelä's avatar
      Bug#12612184 Race condition after btr_cur_pessimistic_update() · 5b4ceba5
      Marko Mäkelä authored
      btr_cur_compress_if_useful(), btr_compress(): Add the parameter ibool
      adjust. If adjust=TRUE, adjust the cursor position after compressing
      the page.
      
      btr_lift_page_up(): Return a pointer to the father page.
      
      BTR_KEEP_POS_FLAG: A new flag for btr_cur_pessimistic_update().
      
      btr_cur_pessimistic_update(): If *big_rec != NULL and flags &
      BTR_KEEP_POS_FLAG, keep the cursor positioned on the updated record.
      Also, do not release the index tree x-lock if *big_rec != NULL.
      
      btr_cur_mtr_commit_and_start(): Commits and restarts a
      mini-transaction so that it will retain an x-lock on index->lock and
      the page of the cursor. This is invoked when
      btr_cur_pessimistic_update() returns *big_rec != NULL.
      
      In all callers of btr_cur_pessimistic_update() that do not pass
      BTR_KEEP_POS_FLAG, assert that *big_rec == NULL.
      
      btr_cur_compress(): Unused function [in the built-in MySQL 5.1], remove.
      
      page_rec_get_nth(): Return the nth record on the page (an inverse
      function of page_rec_get_n_recs_before()). Refactored from
      page_get_middle_rec().
      
      page_get_middle_rec(): Invoke page_rec_get_nth().
      
      page_cur_insert_rec_zip_reorg(): Make use of the page directory
      shortcuts in page_rec_get_nth() instead of scanning the whole list of
      records.
      
      row_ins_clust_index_entry_by_modify(): Pass BTR_KEEP_POS_FLAG to
      btr_cur_pessimistic_update().
      
      row_ins_index_entry_low(): If row_ins_clust_index_entry_by_modify()
      returns a big_rec, invoke btr_cur_mtr_commit_and_start() in order to
      commit and start the mini-transaction without releasing the x-locks on
      index->lock and the cursor page, and write the big_rec. Releasing the
      page latch in mtr_commit() caused a race condition.
      
      row_upd_clust_rec(): Pass BTR_KEEP_POS_FLAG to
      btr_cur_pessimistic_update(). If it returns a big_rec, invoke
      btr_cur_mtr_commit_and_start() in order to commit and start the
      mini-transaction without releasing the x-locks on index->lock and the
      cursor page, and write the big_rec. Releasing the page latch in
      mtr_commit() caused a race condition.
      
      sync_thread_add_level(): Add the parameter ibool relock. When TRUE,
      bypass the latching order rules.
      
      rw_lock_add_debug_info(): For nested X-lock requests, pass relock=TRUE
      to sync_thread_add_level().
      
      rb:678 approved by Jimmy Yang
      5b4ceba5
  6. 15 Jun, 2011 1 commit
    • Marko Mäkelä's avatar
      Introduce UNIV_BLOB_NULL_DEBUG for temporarily hiding Bug#12650861. · a8629376
      Marko Mäkelä authored
      Some ut_a(!rec_offs_any_null_extern()) assertion failures are indicating
      genuine BLOB bugs, others are bogus failures when rolling back incomplete
      transactions at crash recovery. This needs more work, and until I get a
      chance to work on it, other testing must not be disrupted by this.
      a8629376
  7. 14 Jun, 2011 1 commit
    • Marko Mäkelä's avatar
      Merge a fix from mysql-5.5 to mysql-5.1: · 98d527d3
      Marko Mäkelä authored
      revno 2995.37.209
      revision id marko.makela@oracle.com-20110518120508-qhn7vz814vn77v5k
      parent marko.makela@oracle.com-20110517121555-lmple24qzxqkzep4
      timestamp: Wed 2011-05-18 15:05:08 +0300
      message:
        Fix a bogus UNIV_SYNC_DEBUG failure in the fix of Bug #59641
        or Oracle Bug #11766513.
      
        trx_undo_free_prepared(): Do not acquire or release trx->rseg->mutex.
        This code is invoked in the single-threaded part of shutdown, therefore
        a mutex is not needed.
      98d527d3
  8. 13 Jun, 2011 1 commit
  9. 10 Jun, 2011 4 commits
    • Karen Langford's avatar
      Merged from mysql-5.0 · e06e1767
      Karen Langford authored
      e06e1767
    • Karen Langford's avatar
      increase version number to 5.0.95 · 93823c52
      Karen Langford authored
      93823c52
    • Karen Langford's avatar
      Raise version number after cloning 5.1.58 · 9cfba6a7
      Karen Langford authored
      9cfba6a7
    • Dmitry Shulga's avatar
      Fixed bug#11753738 (formely known as bug#45235) - 5.1 DOES NOT SUPPORT 5.0-ONLY · 1fea8c1b
      Dmitry Shulga authored
      SYNTAX TRIGGERS IN ANY WAY
      
      Table with triggers which were using deprecated (5.0-only) syntax became
      unavailable for any DML and DDL after upgrade to 5.1 version of server.
      Attempt to execute any statement on such a table resulted in parsing
      error reported. Since this included DROP TRIGGER and DROP TABLE
      statements (actually, the latter was allowed but was not functioning
      properly for such tables) it was impossible to fix the problem without
      manual operations on .TRG and .TRN files in data directory.
      
      The problem was that failure to parse trigger body (due to 5.0-only
      syntax) when opening trigger file for a table prevented the table
      from being open. This made all operations on the table impossible
      (except DROP TABLE which due to peculiarity in its implementation
      dropped the table but left trigger files around).
      
      This patch solves this problem by silencing error which occurs when
      we parse trigger body during table open. Error message is preserved
      for the future use and table is marked as having a broken trigger.
      We also try to analyze parse tree to recover trigger name, which
      will be needed in order to drop the broken trigger. DML statements
      which invoke triggers on the table marked as having broken trigger
      are prohibited and emit saved error message. The same happens for
      DDL which change triggers except DROP TRIGGER and DROP TABLE which
      try their best to do what was requested. Table becomes no longer
      marked as having broken trigger when last such trigger is dropped.
      
      mysql-test/r/trigger-compat.result:
        Add results for test case for bug#45235
      mysql-test/t/trigger-compat.test:
        Add test case for bug#45235.
      sql/sp_head.cc:
        Added protection against MEM_ROOT double restoring to
        sp_head::restore_thd_mem_root() method. Since this
        method can be sometimes called twice during parsing
        of stored routine (the first time during normal flow
        of parsing, and the second time when a syntax error
        is detected) we need to shortcut execution of the
        method to avoid damaging MEM_ROOT by the second
        consecutive call to this method.
      sql/sql_trigger.cc:
        Added error handler Deprecated_trigger_syntax_handler to 
        catch non-OOM errors during parsing of trigger body.
        
        Added handling of parse errors into method 
        Table_triggers_list::check_n_load().
      sql/sql_trigger.h:
        Added new members to handle broken triggers and error messages.
      1fea8c1b
  10. 09 Jun, 2011 4 commits
    • Marko Mäkelä's avatar
      Disable a debug assertion that was added to track down Bug#12612184. · 4412b5da
      Marko Mäkelä authored
      row_build(): The record may contain null BLOB pointers when the server
      is rolling back an insert that was interrupted by a server crash.
      4412b5da
    • Dmitry Shulga's avatar
      Follow-up for patch of bug#11764334. · 53e4a852
      Dmitry Shulga authored
      53e4a852
    • Dmitry Shulga's avatar
      Fixed bug#11764334 (formerly bug#57156): ALTER EVENT CHANGES · fa913a0b
      Dmitry Shulga authored
      THE EVENT STATUS.
      
      Any ALTER EVENT statement on a disabled event enabled it back
      (unless this ALTER EVENT statement explicitly disabled the event).
      
      The problem was that during processing of an ALTER EVENT statement
      value of status field was overwritten unconditionally even if new
      value was not specified explicitly. As a consequence this field
      was set to default value for status which corresponds to ENABLE.
      
      The solution is to check if status field was explicitly specified in
      ALTER EVENT statement before assigning new value to status field.
      
      mysql-test/r/events_bugs.result:
        test's result for Bug#11764334 was added.
      mysql-test/t/events_bugs.test:
        new test for Bug#11764334 was added.
      sql/event_db_repository.cc:
        mysql_event_fill_row() was modified: set value for status field
        in events tables only in case if statement CREATE EVENT
        is being processed or if this value was set in ALTER EVENT
        statement.
        Event_db_repository::create_event was modified: removed redundant
        setting of status field after return from call to mysql_event_fill_row().
      sql/event_parse_data.h:
        Event_parse_data structure was modified: added flag
        status_changed that is set to true if status's value
        was changed in ALTER EVENT statement.
      sql/sql_yacc.yy:
        Set flag status_changed if status was set in ALTER EVENT
        statement.
      fa913a0b
    • Marko Mäkelä's avatar
      BLOB instrumentation for Bug#12612184 Race condition in row_upd_clust_rec() · 6348b737
      Marko Mäkelä authored
      If UNIV_DEBUG or UNIV_BLOB_LIGHT_DEBUG is enabled, add
      !rec_offs_any_null_extern() assertions, ensuring that records do not
      contain null pointers to externally stored columns in inappropriate
      places.
      
      btr_cur_optimistic_update(): Assert !rec_offs_any_null_extern().
      Incomplete records must never be updated or deleted. This assertion
      will cover also the pessimistic route.
      
      row_build(): Assert !rec_offs_any_null_extern(). Search tuples must
      never be built from incomplete index entries.
      
      row_rec_to_index_entry(): Assert !rec_offs_any_null_extern() unless
      ROW_COPY_DATA is requested. ROW_COPY_DATA is used for
      multi-versioning, and therefore it might be valid to copy the most
      recent (uncommitted) version while it contains a null pointer to
      off-page columns.
      
      row_vers_build_for_consistent_read(),
      row_vers_build_for_semi_consistent_read(): Assert !rec_offs_any_null_extern()
      on all versions except the most recent one.
      
      trx_undo_prev_version_build(): Assert !rec_offs_any_null_extern() on
      the previous version.
      
      rb:682 approved by Sunny Bains
      6348b737
  11. 07 Jun, 2011 1 commit
    • Ramil Kalimullin's avatar
      Bug#11764487: myisam corruption with insert ignore and invalid spatial data · 768b9a0e
      Ramil Kalimullin authored
      Problem: in case of wrong data insert into indexed GEOMETRY fields 
      (e.g. NULL value for a not NULL field) MyISAM reported 
      "ERROR 126 (HY000): Incorrect key file for table; try to repair it"
      due to misuse of the key deletion function.
      
      Fix: always use R-tree key functions for R-tree based indexes
      and B-tree key functions for B-tree based indexes.
      
      
      mysql-test/r/gis-rtree.result:
        Bug#11764487: myisam corruption with insert ignore and invalid spatial data
          - test result.
      mysql-test/t/gis-rtree.test:
        Bug#11764487: myisam corruption with insert ignore and invalid spatial data
          - test case.
      storage/myisam/mi_update.c:
        Bug#11764487: myisam corruption with insert ignore and invalid spatial data
          - handling update errors check for HA_ERR_NULL_IN_SPATIAL as well to be 
        consistent with mi_write();
          - always use keyinfo->ck_delete()/ck_insert() instead of _mi_ck_delete()/_mi_ck_write()
        to handle index properly, as it may be of B-tree or R-tree type.
      storage/myisam/mi_write.c:
        Bug#11764487: myisam corruption with insert ignore and invalid spatial data
          - always use keyinfo->ck_delete() instead of _mi_ck_delete() to handle
        index properly, as it may be of B-tree or R-tree type.
      768b9a0e
  12. 06 Jun, 2011 1 commit
    • Georgi Kodinov's avatar
      Bug #11749418: 38965: TEST CASES GIS-RTREE, TYPE_FLOAT, TYPE_NEWDECIMAL · b502a64b
      Georgi Kodinov authored
        FAIL IN EMBEDDED SERVER
      
      FreeBSD 64 bit needs the FP_X_DNML to fpsetmask() to prevent exceptions from
      propagating into mysql (as a threaded application).
      However fpsetmask() itself is deprecated in favor of fedisableexcept().
      1. Fixed the #ifdef to check for FP_X_DNML instead of i386.
      2. Added a configure.in check for fedisableexcept() and, if present,
         this function is called insted of the fpsetmask().
      No need for new tests, as the existing tests cover this already.
      Removed the affected tests from the experimental list.
      b502a64b
  13. 03 Jun, 2011 2 commits
  14. 30 May, 2011 1 commit
    • Davi Arnaut's avatar
      Bug#12563279: REGRESSION IN HANDLING PRE-4.1 AUTHENTICATION PACKET · 9b68760f
      Davi Arnaut authored
      The problem is that clients implementing the 4.0 version of the
      protocol (that is, mysql-4.0) do not null terminate a string
      at the end of the authentication packet. These clients denote
      the end of the string with the end of the packet.
      
      Although this goes against the documented (see MySQL Internals
      ClientServer Protocol wiki) description of the protocol, these
      old clients still need to be supported.
      
      The solution is to support the documented and actual behavior
      of the clients. If a client is using the pre-4.1 version of
      the protocol, the end of a string in the authentication packet
      can either be denoted with a null character or by the end of
      the packet. This restores backwards compatibility with old
      clients implementing either the documented or actual behavior.
      
      sql/password.c:
        The scrambled message, as provided by the user, might not be
        properly null terminated. If this is the case, uninitialized
        memory past the end of the buffer could theoretically be
        accessed. To ensure that this is never the case, copy the
        scrambled message over to a null terminated auxiliar buffer.
      sql/sql_connect.cc:
        Use different execution paths to read strings depending on the
        protocol being used. If version 4.0 of the protocol is used,
        end of string can be denoted with a NUL character or by the
        end of the packet.
        
        If there are not enough bytes left after the current position
        of the buffer to satisfy the current string, the string is
        considered to be empty. This is required because old clients
        do not send the password string field if the password is empty.
      9b68760f
  15. 27 May, 2011 2 commits
    • Davi Arnaut's avatar
      BUG 11763056 - 55721: AIX 5.1.50 build failing, cannot locate bzero · 05098831
      Davi Arnaut authored
      The problem is that although AIX implements bzero, its prototype
      is not declared by default. Since AC_CHECK_FUNC(bzero) succeeds
      even though a prototype is not declared, this breaks compilation
      in C++ files where a prototype is required.
      
      The solution is to only use bzero if a prototype is also declared.
      
      configure.in:
        Check if bzero is declared. No need to specify the includes,
        unisted.h and strings.h are already part of AC_INCLUDES_DEFAULT.
      05098831
    • Dmitry Shulga's avatar
      Fixed bug#12546938 (formerly known as 61005) - CREATE IF NOT EXIST EVENT · 56a735b7
      Dmitry Shulga authored
      will create multiple running events.
      
      A CREATE IF NOT EXIST on an event that existed and was enabled caused
      multiple instances of the event to run. Disabling the event didn't  help.
      If the event was  dropped, the event stopped running, but when created
      again, multiple instances of the event were still running. The only way
      to get out of this situation was  to restart the server.
      
      The problem was that Event_db_repository::create_event() didn't return
      enough information to discriminate between situation when event didn't
      exist and was created and when event did exist and was not created
      (but a warning was emitted). As result in the latter case event
      was added to in-memory queue of events second time. And this led to
      unwarranted multiple executions of the same event.
      
      The solution is to add out-parameter to Event_db_repository::create_event()
      method which will signal that event was not created because it already
      exists and so it should not be added to the in-memory queue.
      
      
      mysql-test/r/events_bugs.result:
        Added results for test for Bug#12546938.
      mysql-test/t/events_bugs.test:
        Added test for Bug#12546938.
      sql/event_db_repository.cc:
        Event_db_repository::create_event was modified: set newly added out-parameter
        event_already_exists to true value if event wasn't created because event
        already existed and IF NOT EXIST clause was present.
      sql/event_db_repository.h:
        Added out-parameter 'event_already_exists' to create_event() method.
      sql/events.cc:
        Events::create_event was modified: insert new element into
        event queue only if event was actually created.
      56a735b7
  16. 26 May, 2011 3 commits
    • Dmitry Lenev's avatar
      Fix for bug #11762012 - "54553: INNODB ASSERTS IN · 861291f1
      Dmitry Lenev authored
      HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK".
      
      Attempt to update an InnoDB temporary table under LOCK TABLES
      led to assertion failure in both debug and production builds
      if this temporary table was explicitly locked for READ. The 
      same scenario works fine for MyISAM temporary tables.
      
      The assertion failure was caused by discrepancy between lock 
      that was requested on the rows of temporary table at LOCK TABLES
      time and by update operation. Since SQL-layer requested a 
      read-lock at LOCK TABLES time InnoDB engine assumed that upcoming
      statements which are going to be executed under LOCK TABLES will 
      only read table and therefore should acquire only S-lock.
      An update operation broken this assumption by requesting X-lock.
      
      Possible approaches to fixing this problem are:
      
      1) Skip locking of temporary tables as locking doesn't make any
         sense for connection-local objects.
      2) Prohibit changing of temporary table locked by LOCK TABLES ... 
         READ.
      
      Unfortunately both of these approaches have drawbacks which make 
      them unviable for stable versions of server.
      
      So this patch takes another approach and changes code in such way
      that LOCK TABLES for a temporary table will always request write
      lock. In 5.1 version of this patch switch from read lock to write
      lock is done inside of InnoDBs handler methods as doing it on 
      SQL-layer causes compatibility troubles with FLUSH TABLES WITH
      READ LOCK.
      
      mysql-test/suite/innodb/r/innodb_mysql.result:
        Added test for bug #11762012 - "54553: INNODB ASSERTS IN 
        HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK".
      mysql-test/suite/innodb/t/innodb_mysql.test:
        Added test for bug #11762012 - "54553: INNODB ASSERTS IN 
        HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK".
      mysql-test/suite/innodb_plugin/r/innodb_mysql.result:
        Added test for bug #11762012 - "54553: INNODB ASSERTS IN 
        HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK".
      mysql-test/suite/innodb_plugin/t/innodb_mysql.test:
        Added test for bug #11762012 - "54553: INNODB ASSERTS IN 
        HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK".
      storage/innobase/handler/ha_innodb.cc:
        Assume that a temporary table locked by LOCK TABLES can be updated
        even if it was only locked for read and therefore an X-lock should 
        be always requested for such tables.
      storage/innodb_plugin/handler/ha_innodb.cc:
        Assume that a temporary table locked by LOCK TABLES can be updated
        even if it was only locked for read and therefore an X-lock should 
        be always requested for such tables.
      861291f1
    • Sven Sandberg's avatar
      BUG#12574820: binlog.binlog_tmp_table timing out in daily and weekly trunk run · de377681
      Sven Sandberg authored
      Problem: MYSQL_BIN_LOG::reset_logs acquires mutexes in wrong order.
      The correct order is first LOCK_thread_count and then LOCK_log. This function
      does it the other way around. This leads to deadlock when run in parallel
      with a thread that takes the two locks in correct order. For example, a thread
      that disconnects will take the locks in the correct order.
      Fix: change order of the locks in MYSQL_BIN_LOG::reset_logs:
      first LOCK_thread_count and then LOCK_log.
      
      
      mysql-test/suite/binlog/r/binlog_reset_master.result:
        added result file
      mysql-test/suite/binlog/t/binlog_reset_master.test:
        Added test case that demonstrates deadlock because of wrong mutex order.
        The deadlock is between two threads:
         - RESET MASTER acquires mutexes in wrong order.
         - client thread shutdown code acquires mutexes in right order.
        Actually, this test case does not produce deadlock in 5.1, probably
        the client thread shutdown code does not hold both mutexes at the same
        time. However, the bug existed in 5.1 (mutexes are taken in the wrong
        order) so we push the test case to 5.1 too, to prevent future
        regressions.
      sql/log.cc:
        Change mutex acquisition to the correct order:
        first LOCK_thread_count, then LOCK_log.
      sql/mysqld.cc:
        Add debug code to synchronize test case.
      de377681
    • Sergey Glukhov's avatar
      Bug#12392636 ASSERTION FAILED: SCALE >= 0 && PRECISION > 0 && SCALE <= PRECISION · 3efbf304
      Sergey Glukhov authored
      Assertion happens due to missing NULL value check in
      Item_func_round::fix_length_and_dec() function.
      The fix: added NULL value check for second parameter.
      
      
      mysql-test/r/func_math.result:
        test case
      mysql-test/t/func_math.test:
        test case
      sql/item_func.cc:
        added NULL value check for second parameter.
      3efbf304
  17. 24 May, 2011 4 commits
  18. 22 May, 2011 1 commit