An error occurred fetching the project authors.
  1. 07 Mar, 2011 1 commit
    • Jon Olav Hauglid's avatar
      Bug #11764779 (former 57649) · c2dc4b02
      Jon Olav Hauglid authored
      FLUSH TABLES under FLUSH TABLES <list> WITH READ LOCK leads 
      to assert failure.
      
      This assert was triggered if a statement tried up upgrade a metadata
      lock with an active FLUSH TABLE <list> WITH READ LOCK. The assert 
      checks that the connection already holds a global intention exclusive
      metadata lock. However, FLUSH TABLE <list> WITH READ LOCK does not
      acquire this lock in order to be compatible with FLUSH TABLES WITH
      READ LOCK. Therefore any metadata lock upgrade caused the assert to
      be triggered.
      
      This patch fixes the problem by preventing metadata lock upgrade
      if the connection has an active FLUSH TABLE <list> WITH READ LOCK.
      ER_TABLE_NOT_LOCKED_FOR_WRITE will instead be reported to the client.
      
      Test case added to flush.test.
      c2dc4b02
  2. 25 Jan, 2011 1 commit
  3. 11 Jan, 2011 1 commit
  4. 28 Dec, 2010 1 commit
    • Kent Boortz's avatar
      - Added/updated copyright headers · fddb1f1b
      Kent Boortz authored
      - Removed files specific to compiling on OS/2
      - Removed files specific to SCO Unix packaging
      - Removed "libmysqld/copyright", text is included in documentation
      - Removed LaTeX headers for NDB Doxygen documentation
      - Removed obsolete NDB files
      - Removed "mkisofs" binaries
      - Removed the "cvs2cl.pl" script
      - Changed a few GPL texts to use "program" instead of "library"
      fddb1f1b
  5. 16 Dec, 2010 1 commit
    • Jon Olav Hauglid's avatar
      Bug #58730 Assertion failed: table->key_read == 0 in close_thread_table, · 28a5059a
      Jon Olav Hauglid authored
                 temptable views
      
      The TABLE::key_read field indicates if the optimizer has found that row
      retrieval only should access the index tree. The triggered assert
      inside close_thread_table() checks that this field has been reset when
      the table is about to be closed.
      
      During normal execution, these fields are reset right before tables are
      closed at the end of mysql_execute_command(). But in the case of errors,
      tables are closed earlier. The patch for Bug#52044 refactored the open
      tables code so that close_thread_tables() is called immediately if
      opening of tables fails. At this point in the execution, it could
      happend that all TABLE::key_read fields had not been properly reset,
      therefore triggering the assert.
      
      The problematic statement in this case was EXPLAIN where the query
      accessed two derived tables and where the first derived table was
      processed successfully while the second derived table was not.
      Since it was an EXPLAIN, TABLE::key_read fields were not reset after
      successful derived table processing since the state needs to be 
      accessible afterwards. When processing of the second derived table
      failed, it's corresponding SELECT_LEX_UNIT was cleaned, which caused
      it's TABLE::key_read fields to be reset. Since processing failed,
      the error path of open_and_lock_tables() was entered and
      close_thread_tables() was called. The assert was then triggered due
      to the TABLE::key_read fields set during processing of the first
      derived table.
      
      This patch fixes the problem by adding a new derived table processor,
      mysql_derived_cleanup() that is called after mysql_derived_filling().
      It causes cleanup of all SELECT_LEX_UNITs to be called, resetting
      all relevant TABLE::key_read fields.
      
      Test case added to derived.test.
      28a5059a
  6. 15 Dec, 2010 1 commit
    • Alexander Nozdrin's avatar
      Patch for Bug#57952 (privilege change is not taken into account by EXECUTE). · 39036ca6
      Alexander Nozdrin authored
      The user-visible problem was that changes to column-level privileges,
      happened in between of PREPARE and EXECUTE of a prepared statement, were
      neglected. I.e. a prepared statement could be executed with the
      column-level privileges as of PREPARE-time. The problem existed for
      column-level privileges only.
      
      A similar problem existed for stored programs: the changes between
      executions didn't have an effect.
      
      Technically the thing is that table references are cached in
      Prepared_statement::prepare() call. In subsequent
      Prepared_statement::execute() calls those cached values are used.
      There are two functions to get a field by name: find_field_in_table() and
      find_field_in_table_ref(). On prepare-phase find_field_in_table_ref() is
      called, on execute-phase -- find_field_in_table() because the table is
      cached. find_field_in_table() does not check column-level privileges and
      expects the caller to do that. The problem was that this check was
      forgotten.
      
      The fix is to check them there as it happens in find_field_in_table_ref().
      39036ca6
  7. 11 Nov, 2010 1 commit
    • Dmitry Lenev's avatar
      Patch that refactors global read lock implementation and fixes · 378cdc58
      Dmitry Lenev authored
      bug #57006 "Deadlock between HANDLER and FLUSH TABLES WITH READ
      LOCK" and bug #54673 "It takes too long to get readlock for
      'FLUSH TABLES WITH READ LOCK'".
      
      The first bug manifested itself as a deadlock which occurred
      when a connection, which had some table open through HANDLER
      statement, tried to update some data through DML statement
      while another connection tried to execute FLUSH TABLES WITH
      READ LOCK concurrently.
      
      What happened was that FTWRL in the second connection managed
      to perform first step of GRL acquisition and thus blocked all
      upcoming DML. After that it started to wait for table open
      through HANDLER statement to be flushed. When the first connection
      tried to execute DML it has started to wait for GRL/the second
      connection creating deadlock.
      
      The second bug manifested itself as starvation of FLUSH TABLES
      WITH READ LOCK statements in cases when there was a constant
      stream of concurrent DML statements (in two or more
      connections).
      
      This has happened because requests for protection against GRL
      which were acquired by DML statements were ignoring presence of
      pending GRL and thus the latter was starved.
      
      This patch solves both these problems by re-implementing GRL
      using metadata locks.
      
      Similar to the old implementation acquisition of GRL in new
      implementation is two-step. During the first step we block
      all concurrent DML and DDL statements by acquiring global S
      metadata lock (each DML and DDL statement acquires global IX
      lock for its duration). During the second step we block commits
      by acquiring global S lock in COMMIT namespace (commit code
      acquires global IX lock in this namespace).
      
      Note that unlike in old implementation acquisition of
      protection against GRL in DML and DDL is semi-automatic.
      We assume that any statement which should be blocked by GRL
      will either open and acquires write-lock on tables or acquires
      metadata locks on objects it is going to modify. For any such
      statement global IX metadata lock is automatically acquired
      for its duration.
      
      The first problem is solved because waits for GRL become
      visible to deadlock detector in metadata locking subsystem
      and thus deadlocks like one in the first bug become impossible.
      
      The second problem is solved because global S locks which
      are used for GRL implementation are given preference over
      IX locks which are acquired by concurrent DML (and we can
      switch to fair scheduling in future if needed).
      
      Important change:
      FTWRL/GRL no longer blocks DML and DDL on temporary tables.
      Before this patch behavior was not consistent in this respect:
      in some cases DML/DDL statements on temporary tables were
      blocked while in others they were not. Since the main use cases
      for FTWRL are various forms of backups and temporary tables are
      not preserved during backups we have opted for consistently
      allowing DML/DDL on temporary tables during FTWRL/GRL.
      
      Important change:
      This patch changes thread state names which are used when
      DML/DDL of FTWRL is waiting for global read lock. It is now
      either "Waiting for global read lock" or "Waiting for commit
      lock" depending on the stage on which FTWRL is.
      
      Incompatible change:
      To solve deadlock in events code which was exposed by this
      patch we have to replace LOCK_event_metadata mutex with
      metadata locks on events. As result we have to prohibit
      DDL on events under LOCK TABLES.
      
      This patch also adds extensive test coverage for interaction
      of DML/DDL and FTWRL.
      
      Performance of new and old global read lock implementations
      in sysbench tests were compared. There were no significant
      difference between new and old implementations.
      378cdc58
  8. 14 Oct, 2010 2 commits
  9. 13 Oct, 2010 1 commit
    • Jon Olav Hauglid's avatar
      Bug #55930 Assertion `thd->transaction.stmt.is_empty() || · 4eb32469
      Jon Olav Hauglid authored
                 thd->in_sub_stmt || (thd->state..
      
      OPTIMIZE TABLE is not directly supported by InnoDB. Instead,
      recreate and analyze of the table is done. After recreate,
      the table is closed and locks are released before the table
      is reopened and locks re-acquired for the analyze phase.
      
      This assertion was triggered if OPTIMIZE TABLE failed to
      acquire thr_lock locks before starting the analyze phase.
      The assertion tests (among other things) that there no
      active statement transaction. However, as part of acquiring
      the thr_lock lock, external_lock() is called for InnoDB
      tables and this causes a statement transaction to be started.
      If thr_multi_lock() later fails (e.g. due to timeout),
      the failure handling code causes this assert to be triggered.
      
      This patch fixes the problem by doing rollback of the
      current statement transaction in case open_ltable (used by
      OPTIMIZE TABLE) fails to acquire thr_lock locks.
      
      Test case added to lock_sync.test.
      4eb32469
  10. 11 Oct, 2010 1 commit
    • 's avatar
      Bug#56226 Table map set to 0 after altering MyISAM table · d7767d4a
      authored
      After ALTER TABLE which changed only table's metadata, row-based
      binlog sometimes got corrupted since the tablemap was unexpectedly
      set to 0 for subsequent updates to the same table.
      
      ALTER TABLE which changed only table's metadata always reset
      table_map_id for the table share to 0. Despite the fact that
      0 is a valid value for table_map_id, this step caused problems
      as it could have created situation in which we had more than
      one table share with table_map_id equal 0. If more than one
      table with table_map_id are 0 were updated in the same statement,
      updates to these different tables were written into the same
      rows event. This caused slave server to crash.
      
      This bug happens only on 5.1. It doesn't affect 5.5+.
      
      This patch solves this problem by ensuring that ALTER TABLE
      statements which change metadata only never reset table_map_id
      to 0. To do this it changes reopen_table() to correctly use
      refreshed table_map_id value instead of using the old one/
      resetting it.
      d7767d4a
  11. 30 Sep, 2010 1 commit
  12. 24 Sep, 2010 1 commit
  13. 15 Sep, 2010 1 commit
    • Dmitry Lenev's avatar
      Fix for bug #56251 "Deadlock with INSERT DELAYED and MERGE · 6d5065a9
      Dmitry Lenev authored
      tables".
      
      Attempting to issue an INSERT DELAYED statement for a MERGE
      table might have caused a deadlock if it happened as part of
      a transaction or under LOCK TABLES, and there was a concurrent
      DDL or LOCK TABLES ... WRITE statement which tried to lock one
      of its underlying tables.
      
      The problem occurred when a delayed insert handler thread tried
      to open a MERGE table and discovered that to do this it had also
      to open all underlying tables and hence acquire metadata
      locks on them. Since metadata locks on the underlying tables were
      not pre-acquired by the connection thread executing INSERT DELAYED,
      attempts to do so might lead to waiting. In this case the
      connection thread had to wait for the delayed insert thread.
      If the thread which was preventing the lock on the underlying table
      from being acquired had to wait for the connection thread (due to
      this or other metadata locks), a deadlock occurred. 
      This deadlock was not detected by the MDL deadlock detector since 
      waiting for the handler thread by the connection thread is not
      represented in the wait-for graph.
      
      This patch solves the problem by ensuring that the delayed
      insert handler thread never tries to open underlying tables 
      of a MERGE table. Instead open_tables() is aborted right after
      the parent table is opened and a ER_DELAYED_NOT_SUPPORTED 
      error is emitted (which is passed to the connection thread and
      ultimately to the user).
      6d5065a9
  14. 09 Sep, 2010 1 commit
    • Dmitry Lenev's avatar
      Fix for bug #55273 "FLUSH TABLE tm WITH READ LOCK for Merge · 3326614d
      Dmitry Lenev authored
      table causes assert failure".
      
      Attempting to use FLUSH TABLE table_list WITH READ LOCK
      statement for a MERGE table led to an assertion failure if
      one of its children was not present in the list of tables
      to be flushed. The problem was not visible in non-debug builds.
      
      The assertion failure was caused by the fact that in such
      situations FLUSH TABLES table_list WITH READ LOCK implementation
      tried to use (e.g. lock) such child tables without acquiring
      metadata lock on them. This happened because when opening tables
      we assumed metadata locks on all tables were already acquired
      earlier during statement execution and a such assumption was
      false for MERGE children.
      
      This patch fixes the problem by ensuring at open_tables() time
      that we try to acquire metadata locks on all tables to be opened. 
      For normal tables such requests are satisfied instantly since
      locks are already acquired for them. For MERGE children metadata
      locks are acquired in normal fashion.
      
      Note that FLUSH TABLES merge_table WITH READ LOCK will lock for
      read both the MERGE table and its children but will flush only 
      the MERGE table. To flush children one has to mention them in table
      list explicitly. This is expected behavior and it is consistent with
      usage patterns for this statement (e.g. in mysqlhotcopy script).
      3326614d
  15. 06 Sep, 2010 1 commit
    • Dmitry Lenev's avatar
      A temporary workaround for bug #56405 "Deadlock in the · ac351578
      Dmitry Lenev authored
      MDL deadlock detector".
      
      Deadlock could have occurred when workload containing mix
      of DML, DDL and FLUSH TABLES statements affecting same
      set of tables was executed in heavily concurrent environment.
      
      This deadlock occurred when several connections tried to
      perform deadlock detection in metadata locking subsystem.
      The first connection started traversing wait-for graph,
      encountered sub-graph representing wait for flush, acquired
      LOCK_open and dived into sub-graph inspection. When it has
      encounterd sub-graph corresponding to wait for metadata lock
      and blocked while trying to acquire rd-lock on
      MDL_lock::m_rwlock (*) protecting this subgraph, since some
      other thread had wr-lock on it. When this wr-lock was released
      it could have happened (if there was other pending wr-lock
      against this rwlock) that rd-lock from the first connection
      was left unsatisfied but at the same time new rd-lock request
      from the second connection sneaked in and was satisfied (for
      this to be possible second rd- request should come exactly
      after wr-lock is released but before pending wr-lock manages
      to grab rwlock, which is possible both on Linux and in our
      own rwlock implementation). If this second connection
      continued traversing wait-for graph and encountered sub-graph
      representing wait for flush it tried to acquire LOCK_open
      and thus deadlock was created.
      
      This patch tries to workaround this problem but not allowing
      deadlock detector to lock LOCK_open mutex if some other thread
      doing deadlock detection already owns it and current search
      depth is greater than 0. Instead deadlock is reported.
      
      Other possible solutions are either known to have negative
      effects on performance or require much more time for proper
      implementation and testing.
      
      No test case is provided as this bug is very hard to repeat
      in MTR environment but is repeatable with the help of RQG
      tests.
      ac351578
  16. 31 Aug, 2010 2 commits
    • Alexander Nozdrin's avatar
      Bug#27480 (Extend CREATE TEMPORARY TABLES privilege · d2159e37
      Alexander Nozdrin authored
      to allow temp table operations) -- prerequisite patch #3.
      
      Rename open_temporary_table() to open_table_uncached().
      open_temporary_table() will be introduced in following patches
      to open temporary tables for a statement.
      d2159e37
    • Alexander Nozdrin's avatar
      Bug#27480 (Extend CREATE TEMPORARY TABLES privilege · 2e462c8f
      Alexander Nozdrin authored
      to allow temp table operations) -- prerequisite patch #2.
      
      Introduce a new form of find_temporary_table() function:
      find_temporary_table() by a table key. It will be used
      in further patches.
      
      Replace find_temporary_table(table_list->db, table_list->name)
      by more appropiate find_temporary_table(table_list) across
      the codebase.
      2e462c8f
  17. 27 Aug, 2010 1 commit
    • Alexander Nozdrin's avatar
      Bug#27480 (Extend CREATE TEMPORARY TABLES privilege · 0142c14a
      Alexander Nozdrin authored
      to allow temp table operations) -- prerequisite patch #1.
        
      Move a piece of code that initialiazes TABLE instance
      after it was successfully opened into a separate function.
      This function will be reused in the following patches.
      0142c14a
  18. 20 Aug, 2010 2 commits
    • Jon Olav Hauglid's avatar
      Bug #55973 Assertion `thd->transaction.stmt.is_empty()' · 9bd8a62d
      Jon Olav Hauglid authored
                 on CREATE TABLE .. SELECT I_S.PART
      
      This assert was triggered if an InnoDB table was created using
      CREATE TABLE ... AS SELECT where the query used an I_S table, and
      a view existed in the database. It would also be triggered for
      any statement changing an InnoDB table (e.g. INSERT, UPDATE, DELETE)
      which had a subquery referencing an I_S table.
      
      The assert was triggered if open_normal_and_derived_tables() failed
      and a statement transaction had been started. This will usually not
      happen as tables are opened before a statement transaction is started.
      However, e.g. CREATE TABLE ... AS SELECT starts a transaction in order
      to insert tuples into the new table. And if the subquery references
      an I_S table, all current tables and views can be opened in order to
      fill the I_S table on the fly. If a view is discovered, open will fail
      as it is instructed to open tables only (OPEN_TABLE_ONLY). This would
      cause the assert to be triggered.
      
      The assert was added in the patch for Bug#52044 and was therefore
      not in any released versions of the server.
      
      This patch fixes the problem by adjusting the assert to take into
      consideration the possibility of tables being opened as part of
      an I_S query. This is similar to what is already done for 
      close_tables_for_reopen().
      
      Test case added to information_schema_inno.test.
      9bd8a62d
    • Alfranio Correia's avatar
      BUG#53452 Inconsistent behavior of binlog_direct_non_transactional_updates with · c6d4915f
      Alfranio Correia authored
      temp table
                  
      This patch introduces two key changes in the replication's behavior.
                  
      Firstly, it reverts part of BUG#51894 which puts any update to temporary tables
      into the trx-cache. Now, updates to temporary tables are handled according to
      the type of their engines as a regular table.
                  
      Secondly, an unsafe mixed statement, (i.e. a statement that access transactional
      table as well non-transactional or temporary table, and writes to any of them),
      are written into the trx-cache in order to minimize errors in the execution when
      the statement logging format is in use.
                  
      Such changes has a direct impact on which statements are classified as unsafe
      statements and thus part of BUG#53259 is reverted.
      c6d4915f
  19. 19 Aug, 2010 1 commit
    • Jon Olav Hauglid's avatar
      Bug #56085 Embedded server tests fails with assert in · b02f5dd8
      Jon Olav Hauglid authored
                 check_if_table_exists()
      
      This assert was triggered when the server tried to load plugins
      while running in embedded server mode. In embedded server mode,
      check_if_table_exists() was used to check if mysql.plugin existed
      so that ER_NO_SUCH_TABLE could be silently ignored.
      The problem was that this check was done without acquiring a metadata
      lock on mysql.plugin first. This triggered the assert.
      
      This patch fixes the problem by removing the call to
      check_if_table_exists() from plugin_load(). Instead an error handler
      which traps ER_NO_SUCH_TABLE is installed before trying to open
      mysql.plugin when running in embedded server mode.
      
      No test coverage added since this assert was triggered by 
      existing tests running in embedded server mode.
      b02f5dd8
  20. 18 Aug, 2010 1 commit
    • 's avatar
      WL#5370 Keep forward-compatibility when changing · d3b7cd3f
      authored
              'CREATE TABLE IF NOT EXISTS ... SELECT' behaviour
      BUG#47132, BUG#47442, BUG49494, BUG#23992 and BUG#48814 will disappear
      automatically after the this patch.
      BUG#55617 is fixed by this patch too.
                  
      This is the 5.5 part.
      It implements:
      - 'CREATE TABLE IF NOT EXISTS ... SELECT' statement will not insert
        anything and binlog anything if the table already exists.
        It only generate a warning that table already exists.
      - A couple of test cases for the behavior changing.
      d3b7cd3f
  21. 13 Aug, 2010 1 commit
    • Mattias Jonsson's avatar
      Bug#53676: Unexpected errors and possible table · 9a7a64ac
      Mattias Jonsson authored
                 corruption on ADD PARTITION and LOCK TABLE
      Bug#53770: Server crash at handler.cc:2076 on
                 LOAD DATA after timed out COALESCE PARTITION
      
      5.5 fix for:
      Bug#51042: REORGANIZE PARTITION can leave table in an
                 inconsistent state in case of crash
      Needs to be back-ported to 5.1
      
      5.5 fix for:
      Bug#50418: DROP PARTITION does not interact with
                 transactions
      
      Main problem was non-persistent operations done
      before meta-data lock was taken (53770+53676).
      And 53676 needed to keep the table/partitions opened and locked
      while copying the data to the new partitions.
      
      Also added thorough tests to spot some additional bugs
      in the ddl_log code, which could result in bad state
      between the .frm and partitions.
      
      Collapsed patch, includes all fixes required from the reviewers.
      9a7a64ac
  22. 12 Aug, 2010 1 commit
  23. 10 Aug, 2010 1 commit
  24. 09 Aug, 2010 1 commit
    • Konstantin Osipov's avatar
      A fix for Bug#41158 "DROP TABLE holds LOCK_open during unlink()". · f8bfa328
      Konstantin Osipov authored
      Remove acquisition of LOCK_open around file system operations,
      since such operations are now protected by metadata locks.
      Rework table discovery algorithm to not require LOCK_open.
      
      No new tests added since all MDL locking operations are covered
      in lock.test and mdl_sync.test, and as long as these tests
      pass despite the increased concurrency, consistency must be
      unaffected.
      f8bfa328
  25. 06 Aug, 2010 1 commit
    • Dmitry Lenev's avatar
      Part of fix for bug#52044 "FLUSH TABLES WITH READ LOCK and · a6c00c27
      Dmitry Lenev authored
      FLUSH TABLES <list> WITH READ LOCK are incompatible" to
      be pushed as separate patch.
      
      Replaced thread state name "Waiting for table", which was
      used by threads waiting for a metadata lock or table flush, 
      with a set of names which better reflect types of resources
      being waited for.
      
      Also replaced "Table lock" thread state name, which was used 
      by threads waiting on thr_lock.c table level lock, with more
      elaborate "Waiting for table level lock", to make it 
      more consistent with other thread state names.
      
      Updated test cases and their results according to these 
      changes.
      
      Fixed sys_vars.query_cache_wlock_invalidate_func test to not
      to wait for timeout of wait_condition.inc script.
      a6c00c27
  26. 04 Aug, 2010 1 commit
  27. 27 Jul, 2010 2 commits
    • Dmitry Lenev's avatar
      Fix for bug #52044 "FLUSH TABLES WITH READ LOCK and FLUSH · 5fff906e
      Dmitry Lenev authored
      TABLES <list> WITH READ LOCK are incompatible".
      
      The problem was that FLUSH TABLES <list> WITH READ LOCK
      which was issued when other connection has acquired global
      read lock using FLUSH TABLES WITH READ LOCK was blocked
      and has to wait until global read lock is released.
      
      This issue stemmed from the fact that FLUSH TABLES <list>
      WITH READ LOCK implementation has acquired X metadata locks
      on tables to be flushed. Since these locks required acquiring
      of global IX lock this statement was incompatible with global
      read lock.
      
      This patch addresses problem by using SNW metadata type of
      lock for tables to be flushed by FLUSH TABLES <list> WITH
      READ LOCK. It is OK to acquire them without global IX lock
      as long as we won't try to upgrade those locks. Since SNW
      locks allow concurrent statements using same table FLUSH
      TABLE <list> WITH READ LOCK now has to wait until old
      versions of tables to be flushed go away after acquiring
      metadata locks. Since such waiting can lead to deadlock
      MDL deadlock detector was extended to take into account
      waits for flush and resolve such deadlocks.
      
      As a bonus code in open_tables() which was responsible for
      waiting old versions of tables to go away was refactored.
      Now when we encounter old version of table in open_table()
      we don't back-off and wait for all old version to go away,
      but instead wait for this particular table to be flushed.
      Such approach supported by deadlock detection should reduce
      number of scenarios in which FLUSH TABLES aborts concurrent
      multi-statement transactions.
      
      Note that active FLUSH TABLES <list> WITH READ LOCK still
      blocks concurrent FLUSH TABLES WITH READ LOCK statement
      as the former keeps tables open and thus prevents the
      latter statement from doing flush.
      5fff906e
    • Konstantin Osipov's avatar
      A pre-requisite patch for the fix for Bug#52044. · ec2c3bf2
      Konstantin Osipov authored
      This patch also fixes Bug#55452 "SET PASSWORD is
      replicated twice in RBR mode".
      
      The goal of this patch is to remove the release of 
      metadata locks from close_thread_tables().
      This is necessary to not mistakenly release
      the locks in the course of a multi-step
      operation that involves multiple close_thread_tables()
      or close_tables_for_reopen().
      
      On the same token, move statement commit outside 
      close_thread_tables().
      
      Other cleanups:
      Cleanup COM_FIELD_LIST.
      Don't call close_thread_tables() in COM_SHUTDOWN -- there
      are no open tables there that can be closed (we leave
      the locked tables mode in THD destructor, and this
      close_thread_tables() won't leave it anyway).
      
      Make open_and_lock_tables() and open_and_lock_tables_derived()
      call close_thread_tables() upon failure.
      Remove the calls to close_thread_tables() that are now
      unnecessary.
      
      Simplify the back off condition in Open_table_context.
      
      Streamline metadata lock handling in LOCK TABLES 
      implementation.
      
      Add asserts to ensure correct life cycle of 
      statement transaction in a session.
      
      Remove a piece of dead code that has also become redundant
      after the fix for Bug 37521.
      ec2c3bf2
  28. 22 Jul, 2010 1 commit
    • Luis Soares's avatar
      BUG#55387: binlog.binlog_tmp_table crashes the server · 2773385d
      Luis Soares authored
                 sporadically
      
      There are two problems:
      
      1. When closing temporary tables, during the THD clean up - and
         after the session connection was already closed, there is a
         chance we can push an error into the THD diagnostics area, if
         the writing of the implicit DROP event to the binary log fails
         for some reason. As a consequence an assertion can be
         triggered, because at that point the diagnostics area is
         already set.
      
      2. Using push_warning with MYSQL_ERROR::WARN_LEVEL_ERROR is a 
         bug.
      
      Given that close_temporary_tables is mostly called from
      THD::cleanup - ie, with the session already closed, we fix
      problem #1 by allowing the diagnostics area to be
      overwritten. There is one other place in the code that calls
      close_temporary_tables - while applying Start_log_event_v3. To
      cover that case, we make close_temporary_tables to return the
      error, thus, propagating upwards in the stack.
      
      To fix problem #2, we replace push_warning with sql_print_error.
      2773385d
  29. 20 Jul, 2010 1 commit
    • Davi Arnaut's avatar
      Bug#45288: pb2 returns a lot of compilation warnings on linux · c96b249f
      Davi Arnaut authored
      Fix warnings flagged by the new warning option -Wunused-but-set-variable
      that was added to GCC 4.6 and that is enabled by -Wunused and -Wall. The
      option causes a warning whenever a local variable is assigned to but is
      later unused. It also warns about meaningless pointer dereferences.
      c96b249f
  30. 13 Jul, 2010 1 commit
    • Dmitry Lenev's avatar
      A pre-requisite for patch fixing bug #52044 "FLUSH TABLES · cf93bc71
      Dmitry Lenev authored
      WITH READ LOCK and FLUSH TABLES <list> WITH READ LOCK are
      incompatible", which adds information about waits caused by 
      FLUSH TABLES statement to deadlock detector in MDL subsystem.
      
      Remove API supporting caching of pointers to TABLE_SHARE 
      object in MDL subsystem and all code related to it. 
      
      The problem was that locking requirements of code 
      implementing this API conflicted with locking requirements 
      of code which adds information about waits caused by flushes 
      to deadlock detector in MDL subsystem (the former needed to
      lock LOCK_open or its future equivalent while having 
      write-lock on MDL_lock's rwlock, and the latter needs to be 
      able to read-lock MDL_lock rwlock while owning LOCK_open or 
      its future equivalent).
      
      Since caching of pointers to TABLE_SHARE objects in MDL 
      subsystem didn't bring expected performance benefits we 
      decided to remove caching API rather than try to come up 
      with some complex solution for this problem.
      cf93bc71
  31. 08 Jul, 2010 1 commit
    • Davi Arnaut's avatar
      Bug#34043: Server loops excessively in _checkchunk() when safemalloc is enabled · a10ae353
      Davi Arnaut authored
      Essentially, the problem is that safemalloc is excruciatingly
      slow as it checks all allocated blocks for overrun at each
      memory management primitive, yielding a almost exponential
      slowdown for the memory management functions (malloc, realloc,
      free). The overrun check basically consists of verifying some
      bytes of a block for certain magic keys, which catches some
      simple forms of overrun. Another minor problem is violation
      of aliasing rules and that its own internal list of blocks
      is prone to corruption.
      
      Another issue with safemalloc is rather the maintenance cost
      as the tool has a significant impact on the server code.
      Given the magnitude of memory debuggers available nowadays,
      especially those that are provided with the platform malloc
      implementation, maintenance of a in-house and largely obsolete
      memory debugger becomes a burden that is not worth the effort
      due to its slowness and lack of support for detecting more
      common forms of heap corruption.
      
      Since there are third-party tools that can provide the same
      functionality at a lower or comparable performance cost, the
      solution is to simply remove safemalloc. Third-party tools
      can provide the same functionality at a lower or comparable
      performance cost. 
      
      The removal of safemalloc also allows a simplification of the
      malloc wrappers, removing quite a bit of kludge: redefinition
      of my_malloc, my_free and the removal of the unused second
      argument of my_free. Since free() always check whether the
      supplied pointer is null, redudant checks are also removed.
      
      Also, this patch adds unit testing for my_malloc and moves
      my_realloc implementation into the same file as the other
      memory allocation primitives.
      a10ae353
  32. 02 Jul, 2010 1 commit
    • Davi Arnaut's avatar
      Bug#53445: Build with -Wall and fix warnings that it generates · 93fb8bb2
      Davi Arnaut authored
      Apart strict-aliasing warnings, fix the remaining warnings
      generated by GCC 4.4.4 -Wall and -Wextra flags.
      
      One major source of warnings was the in-house function my_bcmp
      which (unconventionally) took pointers to unsigned characters
      as the byte sequences to be compared. Since my_bcmp and bcmp
      are deprecated functions whose only difference with memcmp is
      the return value, every use of the function is replaced with
      memcmp as the special return value wasn't actually being used
      by any caller.
      
      There were also various other warnings, mostly due to type
      mismatches, missing return values, missing prototypes, dead
      code (unreachable) and ignored return values.
      93fb8bb2
  33. 01 Jul, 2010 2 commits
    • Dmitry Lenev's avatar
      A follow-up for 5.5 version of fix for bug#54360 "Deadlock · 8ad1aa56
      Dmitry Lenev authored
      DROP/ALTER/CREATE DATABASE with open HANDLER".
      
      Remove wait_for_condition() which became unused after 
      database locks were replaced with MDL scoped locks.
      If one needs functionality provided by this call one can 
      always use THD::enter_cond()/exit_cond() methods.
      
      Also removed an unused include from sql_db.cc and updated 
      comment describing one of used includes to reflect current
      situation.
      8ad1aa56
    • Jon Olav Hauglid's avatar
      A 5.5 version of the fix for Bug #54360 "Deadlock DROP/ALTER/CREATE · 41a3dfe4
      Jon Olav Hauglid authored
      DATABASE with open HANDLER"
      
      Remove LOCK_create_db, database name locks, and use metadata locks instead.
      This exposes CREATE/DROP/ALTER DATABASE statements to the graph-based
      deadlock detector in MDL, and paves the way for a safe, deadlock-free
      implementation of RENAME DATABASE.
      
      Database DDL statements will now take exclusive metadata locks on
      the database name, while table/view/routine DDL statements take
      intention exclusive locks on the database name. This prevents race
      conditions between database DDL and table/view/routine DDL.
      (e.g. DROP DATABASE with concurrent CREATE/ALTER/DROP TABLE)
      
      By adding database name locks, this patch implements
      WL#4450 "DDL locking: CREATE/DROP DATABASE must use database locks" and
      WL#4985 "DDL locking: namespace/hierarchical locks".
      
      The patch also changes code to use init_one_table() where appropriate.
      The new lock_table_names() function requires TABLE_LIST::db_length to
      be set correctly, and this is taken care of by init_one_table().
      
      This patch also adds a simple template to help work with 
      the mysys HASH data structure.
      
      Most of the patch was written by Konstantin Osipov.
      41a3dfe4
  34. 29 Jun, 2010 2 commits