An error occurred fetching the project authors.
  1. 31 Aug, 2010 2 commits
  2. 20 Aug, 2010 1 commit
    • 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
  3. 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
  4. 13 Aug, 2010 2 commits
    • Konstantin Osipov's avatar
      Extract reload_acl_and_cache() and flush_tables_with_read_lock() · 4e935a53
      Konstantin Osipov authored
      into an own implementation file.
      4e935a53
    • 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
  5. 12 Aug, 2010 1 commit
  6. 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
  7. 04 Aug, 2010 1 commit
  8. 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
  9. 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
  10. 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
  11. 11 Jun, 2010 1 commit
    • Konstantin Osipov's avatar
      WL#5419 "LOCK_open scalability: make tdc_refresh_version · b1404566
      Konstantin Osipov authored
      an atomic counter"
      
      Split the large LOCK_open section in open_table(). 
      Do not call open_table_from_share() under LOCK_open.
      Remove thd->version.
      
      This fixes
      Bug#50589 "Server hang on a query evaluated using a temporary 
      table"
      Bug#51557 "LOCK_open and kernel_mutex are not happy together"
      Bug#49463 "LOCK_table and innodb are not nice when handler 
      instances are created".
      
      This patch has effect on storage engines that rely on
      ha_open() PSEA method being called under LOCK_open.
      In particular:
      
      1) NDB is broken and left unfixed. NDB relies on LOCK_open
      being kept as part of ha_open(), since it uses auto-discovery.
      While previously the NDB open code was race-prone, now
      it simply fails on asserts.
      
      2) HEAP engine had a race in ha_heap::open() when
      a share for the same table could be added twice
      to the list of shares, or a dangling reference to a share
      stored in HEAP handler. This patch aims to address this
      problem by 'pinning' the newly created share in the 
      internal HEAP engine share list until at least one
      handler instance is created using that share.
      b1404566
  12. 10 Jun, 2010 1 commit
  13. 07 Jun, 2010 1 commit
    • Dmitry Lenev's avatar
      Patch that changes approach to how we acquire metadata · 571acc87
      Dmitry Lenev authored
      locks for DML statements and changes the way MDL locks
      are acquired/granted in contended case.
      
      Instead of backing-off when a lock conflict is encountered
      and waiting for it to go away before restarting open_tables()
      process we now wait for lock to be released without releasing
      any previously acquired locks. If conflicting lock goes away
      we resume opening tables. If waiting leads to a deadlock we
      try to resolve it by backing-off and restarting open_tables()
      immediately.
      
      As result both waiting for possibility to acquire and
      acquiring of a metadata lock now always happen within the
      same MDL API call. This has allowed to make release of a lock
      and granting it to the most appropriate pending request an
      atomic operation.
      Thanks to this it became possible to wake up during release
      of lock only those waiters which requests can be satisfied
      at the moment as well as wake up only one waiter in case
      when granting its request would prevent all other requests
      from being satisfied. This solves thundering herd problem
      which occured in cases when we were releasing some lock and
      woke up many waiters for SNRW or X locks (this was the issue
      in bug#52289 "performance regression for MyISAM in sysbench
      OLTP_RW test".
      This also allowed to implement more fair (FIFO) scheduling
      among waiters with the same priority.
      It also opens the door for introducing new types of requests
      for metadata locks such as low-prio SNRW lock which is
      necessary in order to support LOCK TABLES LOW_PRIORITY WRITE.
      
      Notice that after this sometimes can report ER_LOCK_DEADLOCK
      error in cases in which it has not happened before.
      Particularly we will always report this error if waiting for
      conflicting lock has happened in the middle of transaction
      and resulted in a deadlock. Before this patch the error was
      not reported if deadlock could have been resolved by backing
      off all metadata locks acquired by the current statement.
      571acc87
  14. 01 Jun, 2010 2 commits
  15. 13 May, 2010 1 commit
  16. 28 Apr, 2010 1 commit
    • Konstantin Osipov's avatar
      Committing on behalf or Dmitry Lenev: · 8280fdd3
      Konstantin Osipov authored
      Fix for bug #46947 "Embedded SELECT without FOR UPDATE is
      causing a lock", with after-review fixes.
      
      SELECT statements with subqueries referencing InnoDB tables
      were acquiring shared locks on rows in these tables when they
      were executed in REPEATABLE-READ mode and with statement or
      mixed mode binary logging turned on.
      
      This was a regression which were introduced when fixing
      bug 39843.
      
      The problem was that for tables belonging to subqueries
      parser set TL_READ_DEFAULT as a lock type. In cases when
      statement/mixed binary logging at open_tables() time this
      type of lock was converted to TL_READ_NO_INSERT lock at
      open_tables() time and caused InnoDB engine to acquire
      shared locks on reads from these tables. Although in some
      cases such behavior was correct (e.g. for subqueries in
      DELETE) in case of SELECT it has caused unnecessary locking.
      
      This patch tries to solve this problem by rethinking our
      approach to how we handle locking for SELECT and subqueries.
      Now we always set TL_READ_DEFAULT lock type for all cases
      when we read data. When at open_tables() time this lock
      is interpreted as TL_READ_NO_INSERT or TL_READ depending
      on whether this statement as a whole or call to function
      which uses particular table should be written to the
      binary log or not (if yes then statement should be properly
      serialized with concurrent statements and stronger lock
      should be acquired).
      
      Test coverage is added for both InnoDB and MyISAM.
      
      This patch introduces an "incompatible" change in locking
      scheme for subqueries used in SELECT ... FOR UPDATE and
      SELECT .. IN SHARE MODE.
      In 4.1 the server would use a snapshot InnoDB read for 
      subqueries in SELECT FOR UPDATE and SELECT .. IN SHARE MODE
      statements, regardless of whether the binary log is on or off.
      If the user required a different type of read (i.e. locking read),
      he/she could request so explicitly by providing FOR UPDATE/IN SHARE MODE
      clause for each individual subquery.
      On of the patches for 5.0 broke this behaviour (which was not documented
      or tested), and started to use locking reads fora all subqueries in SELECT ... 
      FOR UPDATE/IN SHARE MODE. This patch restored 4.1 behaviour.
      8280fdd3
  17. 12 Apr, 2010 1 commit
  18. 31 Mar, 2010 1 commit
    • Mats Kindahl's avatar
      WL#5030: Split and remove mysql_priv.h · e409d6f6
      Mats Kindahl authored
      This patch:
      
      - Moves all definitions from the mysql_priv.h file into
        header files for the component where the variable is
        defined
      - Creates header files if the component lacks one
      - Eliminates all include directives from mysql_priv.h
      - Eliminates all circular include cycles
      - Rename time.cc to sql_time.cc
      - Rename mysql_priv.h to sql_priv.h
      e409d6f6