An error occurred fetching the project authors.
  1. 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
  2. 24 Sep, 2010 1 commit
    • Jon Olav Hauglid's avatar
      Bug #54920 Stored functions are allowed in HANDLER statements, · 11c4d8ba
      Jon Olav Hauglid authored
                 but broken.
      
      Before this patch, it was allowed to use stored functions in
      HANDLER ... READ statements. The problem was that this functionality
      was not really supported by the code. Proper locking would for example
      not be performed, and it was also possible to break replication by
      having stored functions that performed updates.
      
      This patch disallows the use of stored functions in HANDLER ... READ.
      Any such statement will now give an ER_NOT_SUPPORTED_YET error.
      This is an incompatible change and should be reflected in the
      documentation.
      
      Test case added to handler_myisam/handler_innodb.test.
      11c4d8ba
  3. 05 Jul, 2010 1 commit
    • Jon Olav Hauglid's avatar
      Bug #54401 assert in Diagnostics_area::set_eof_status , HANDLER · ecfd9958
      Jon Olav Hauglid authored
      This assert checks that the server does not try to send EOF to the
      client if there has been some error during processing. This to make
      sure that the error is in fact sent to the client.
      
      The problem was that any errors during processing of WHERE conditions
      in HANDLER ... READ statements where not detected by the handler code.
      The handler code therefore still tried to send EOF to the client,
      triggering the assert. The bug was only noticeable in debug builds.
      
      This patch fixes the problem by making sure that the handler code
      checks for errors during condition processing and acts accordingly.
      ecfd9958
  4. 09 Jun, 2010 1 commit
  5. 25 Mar, 2010 1 commit
    • Sergey Vojtovich's avatar
      BUG#51877 - HANDLER interface causes invalid memory read · ba33a335
      Sergey Vojtovich authored
      Invalid memory read if HANDLER ... READ NEXT is executed
      after failed (e.g. empty table) HANDLER ... READ FIRST.
      
      The problem was that we attempted to perform READ NEXT,
      whereas there is no pivot available from failed READ FIRST.
      
      With this fix READ NEXT after failed READ FIRST equals
      to READ FIRST.
      
      This bug affects MyISAM tables only.
      ba33a335
  6. 25 Feb, 2010 1 commit
    • Jon Olav Hauglid's avatar
      Bug #51355 handler stmt cause assertion in · 3eead1f0
      Jon Olav Hauglid authored
                 bool MDL_context::try_acquire_lock(MDL_request*)
      
      This assert was triggered in the following way:
      1) HANDLER OPEN t1 from connection 1
      2) DROP TABLE t1 from connection 2. This will block due to the metadata lock
      held by the open handler in connection 1.
      3) DML statement (e.g. INSERT) from connection 1. This will close the table
      opened by the HANDLER in 1) and release its metadata lock. This is done due
      to the pending exclusive metadata lock from 2). 
      4) DROP TABLE t1 from connection 2 now completes and removes table t1.
      5) HANDLER READ from connection 1. Since the handler table was closed in 3),
      the handler code will try to reopen the table. First a new metadata lock on
      t1 will be granted before the command fails since the table was removed in 4).
      6) HANDLER READ from connection 1. This caused the assert.
      
      The reason for the assert was that the MDL_request's pointer to the lock
      ticket was not reset when the statement failed. HANDLER READ then tried to
      acquire a lock using the same MDL_request object, triggering the assert.
      This bug was only noticeable on debug builds and did not cause any problems
      on release builds.
      
      This patch fixes the problem by assuring that the pointer to the metadata 
      lock ticket is reset when reopening of handler tables fails.
      
      Test case added to handler.inc
      3eead1f0
  7. 15 Feb, 2010 1 commit
    • Dmitry Lenev's avatar
      Fix for bug #51136 "Crash in pthread_rwlock_rdlock on · 68710e2b
      Dmitry Lenev authored
      TEMPORARY + HANDLER + LOCK + SP".
      
      Server crashed when one: 
      1) Opened HANDLER or acquired global read lock
      2) Then locked one or several temporary tables with
         LOCK TABLES statement (but no base tables).
      3) Then issued any statement causing commit (explicit 
         or implicit).
      4) Issued statement which should have closed HANDLER
         or released global read lock.
         
      The problem was that when entering LOCK TABLES mode in the
      scenario described above we incorrectly set transactional
      MDL sentinel to zero. As result during commit all metadata 
      locks were released (including lock for open HANDLER or
      global metadata shared lock). Indeed, attempt to release
      metadata lock for the second time which happened during
      HANLDER CLOSE or during release of GLR caused crash.
      
      This patch fixes problem by changing MDL_context's
      set_trans_sentinel() method to set sentinel to correct 
      value (it should point to the most recent ticket).
      68710e2b
  8. 12 Feb, 2010 1 commit
    • Dmitry Lenev's avatar
      Fix for bug #50908 "Assertion `handler_tables_hash.records == 0' · 0ec868ca
      Dmitry Lenev authored
      failed in enter_locked_tables_mode".
      
      Server was aborted due to assertion failure when one tried to 
      execute statement requiring prelocking (i.e. firing triggers
      or using stored functions) while having open HANDLERs.
      
      The problem was that THD::enter_locked_tables_mode() method
      which was called at the beginning of execution of prelocked 
      statement assumed there are no open HANDLERs. It had to do 
      so because corresponding THD::leave_locked_tables_mode()
      method was unable to properly restore MDL sentinel when
      leaving LOCK TABLES/prelocked mode in the presence of open 
      HANDLERs.
      
      This patch solves this problem by changing the latter method
      to properly restore MDL sentinel and thus removing need for 
      this assumption. As a side-effect, it lifts unjustified
      limitation by allowing to keep HANDLERs open when entering 
      LOCK TABLES mode.
      0ec868ca
  9. 06 Feb, 2010 1 commit
    • Jon Olav Hauglid's avatar
      Bug #50912 Assertion `ticket->m_type >= mdl_request->type' · a4819c5d
      Jon Olav Hauglid authored
                 failed on HANDLER + I_S
      
      This assert was triggered when an I_S query tried to acquire a
      metadata lock on a table which was already locked by a HANDLER
      statement in the same connection.
      
      First the HANDLER took a MDL_SHARED lock. Afterwards, the I_S query
      requested a MDL_SHARED_HIGH_PRIO lock. The existing MDL_SHARED ticket
      is found in find_ticket() since it satisfies 
      ticket->has_stronger_or_equal_type(mdl_request->type) as MDL_SHARED
      and MDL_SHARED_HIGH_PRIO have equal strengths, just different priority.
      
      However, two asserts later check lock type strengths using relational
      operators (>= and <=) rather than MDL_ticket::has_stronger_or_equal_type().
      These asserts are triggered since MDL_SHARED >= MDL_SHARED_HIGH_PRIORITY
      is false (mapped to 1 and 2 respectively).
      
      This patch updates the asserts to use MDL_ticket::has_stronger_or_equal_type()
      rather than relational operators to check lock type strength.
      
      Test case added to include/handler.inc.
      a4819c5d
  10. 05 Feb, 2010 1 commit
    • Jon Olav Hauglid's avatar
      Bug #50907 Assertion `hash_tables->table->next == __null' on · 1ca7c519
      Jon Olav Hauglid authored
                 HANDLER OPEN
      
      The problem was a too restrictive assert in the code for 
      HANDLER ... OPEN and HANDLER ... READ that checked table->next
      to verify that we didn't open views or merge tables.
      
      This pointer is also used to link temporary tables together
      (see thd->temporary_tables). In this case TABLE::next can be
      set even if we're trying to open a single table.
      
      This patch adjust the two asserts to also check for the presence
      of temporary tables.
      
      Test case added to handler_myisam.test.
      1ca7c519
  11. 01 Feb, 2010 1 commit
    • Dmitry Lenev's avatar
      Implement new type-of-operation-aware metadata locks. · afd15c43
      Dmitry Lenev authored
      Add a wait-for graph based deadlock detector to the
      MDL subsystem.
      
      Fixes bug #46272 "MySQL 5.4.4, new MDL: unnecessary deadlock" and
      bug #37346 "innodb does not detect deadlock between update and
      alter table".
      
      The first bug manifested itself as an unwarranted abort of a
      transaction with ER_LOCK_DEADLOCK error by a concurrent ALTER
      statement, when this transaction tried to repeat use of a
      table, which it has already used in a similar fashion before
      ALTER started.
      
      The second bug showed up as a deadlock between table-level
      locks and InnoDB row locks, which was "detected" only after
      innodb_lock_wait_timeout timeout.
      
      A transaction would start using the table and modify a few
      rows.
      Then ALTER TABLE would come in, and start copying rows
      into a temporary table. Eventually it would stumble on
      the modified records and get blocked on a row lock.
      The first transaction would try to do more updates, and get
      blocked on thr_lock.c lock.
      This situation of circular wait would only get resolved
      by a timeout.
      
      Both these bugs stemmed from inadequate solutions to the
      problem of deadlocks occurring between different
      locking subsystems.
      
      In the first case we tried to avoid deadlocks between metadata
      locking and table-level locking subsystems, when upgrading shared
      metadata lock to exclusive one.
      Transactions holding the shared lock on the table and waiting for
      some table-level lock used to be aborted too aggressively.
      
      We also allowed ALTER TABLE to start in presence of transactions
      that modify the subject table. ALTER TABLE acquires
      TL_WRITE_ALLOW_READ lock at start, and that block all writes
      against the table (naturally, we don't want any writes to be lost
      when switching the old and the new table). TL_WRITE_ALLOW_READ
      lock, in turn, would block the started transaction on thr_lock.c
      lock, should they do more updates. This, again, lead to the need
      to abort such transactions.
      
      The second bug occurred simply because we didn't have any
      mechanism to detect deadlocks between the table-level locks
      in thr_lock.c and row-level locks in InnoDB, other than
      innodb_lock_wait_timeout.
      
      This patch solves both these problems by moving lock conflicts
      which are causing these deadlocks into the metadata locking
      subsystem, thus making it possible to avoid or detect such
      deadlocks inside MDL.
      
      To do this we introduce new type-of-operation-aware metadata
      locks, which allow MDL subsystem to know not only the fact that
      transaction has used or is going to use some object but also what
      kind of operation it has carried out or going to carry out on the
      object.
      
      This, along with the addition of a special kind of upgradable
      metadata lock, allows ALTER TABLE to wait until all
      transactions which has updated the table to go away.
      This solves the second issue.
      Another special type of upgradable metadata lock is acquired
      by LOCK TABLE WRITE. This second lock type allows to solve the
      first issue, since abortion of table-level locks in event of
      DDL under LOCK TABLES becomes also unnecessary.
      
      Below follows the list of incompatible changes introduced by
      this patch:
      
      - From now on, ALTER TABLE and CREATE/DROP TRIGGER SQL (i.e. those
        statements that acquire TL_WRITE_ALLOW_READ lock)
        wait for all transactions which has *updated* the table to
        complete.
      
      - From now on, LOCK TABLES ... WRITE, REPAIR/OPTIMIZE TABLE
        (i.e. all statements which acquire TL_WRITE table-level lock) wait
        for all transaction which *updated or read* from the table
        to complete.
        As a consequence, innodb_table_locks=0 option no longer applies
        to LOCK TABLES ... WRITE.
      
      - DROP DATABASE, DROP TABLE, RENAME TABLE no longer abort
        statements or transactions which use tables being dropped or
        renamed, and instead wait for these transactions to complete.
      
      - Since LOCK TABLES WRITE now takes a special metadata lock,
        not compatible with with reads or writes against the subject table
        and transaction-wide, thr_lock.c deadlock avoidance algorithm
        that used to ensure absence of deadlocks between LOCK TABLES
        WRITE and other statements is no longer sufficient, even for
        MyISAM. The wait-for graph based deadlock detector of MDL
        subsystem may sometimes be necessary and is involved. This may
        lead to ER_LOCK_DEADLOCK error produced for multi-statement
        transactions even if these only use MyISAM:
      
        session 1:         session 2:
        begin;
      
        update t1 ...      lock table t2 write, t1 write;
                           -- gets a lock on t2, blocks on t1
      
        update t2 ...
        (ER_LOCK_DEADLOCK)
      
      - Finally,  support of LOW_PRIORITY option for LOCK TABLES ... WRITE
        was abandoned.
        LOCK TABLE ... LOW_PRIORITY WRITE from now on has the same
        priority as the usual LOCK TABLE ... WRITE.
        SELECT HIGH PRIORITY no longer trumps LOCK TABLE ... WRITE  in
        the wait queue.
      
      - We do not take upgradable metadata locks on implicitly
        locked tables. So if one has, say, a view v1 that uses
        table t1, and issues:
        LOCK TABLE v1 WRITE;
        FLUSH TABLE t1; -- (or just 'FLUSH TABLES'),
        an error is produced.
        In order to be able to perform DDL on a table under LOCK TABLES,
        the table must be locked explicitly in the LOCK TABLES list.
      afd15c43
  12. 21 Jan, 2010 1 commit
    • Dmitry Lenev's avatar
      Patch that changes metadata locking subsystem to use mutex per lock and · a63f8480
      Dmitry Lenev authored
      condition variable per context instead of one mutex and one conditional
      variable for the whole subsystem.
      
      This should increase concurrency in this subsystem.
      
      It also opens the way for further changes which are necessary to solve
      such bugs as bug #46272 "MySQL 5.4.4, new MDL: unnecessary deadlock"
      and bug #37346 "innodb does not detect deadlock between update and alter
      table".
      
      Two other notable changes done by this patch:
      
      - MDL subsystem no longer implicitly acquires global intention exclusive
        metadata lock when per-object metadata lock is acquired. Now this has
        to be done by explicit calls outside of MDL subsystem.
      - Instead of using separate MDL_context for opening system tables/tables
        for purposes of I_S we now create MDL savepoint in the main context
        before opening tables and rollback to this savepoint after closing
        them. This means that it is now possible to get ER_LOCK_DEADLOCK error
        even not inside a transaction. This might happen in unlikely case when
        one runs DDL on one of system tables while also running DDL on some
        other tables. Cases when this ER_LOCK_DEADLOCK error is not justified
        will be addressed by advanced deadlock detector for MDL subsystem which
        we plan to implement.
      a63f8480
  13. 30 Dec, 2009 1 commit
    • Dmitry Lenev's avatar
      Implementation of simple deadlock detection for metadata locks. · 236539b4
      Dmitry Lenev authored
      This change is supposed to reduce number of ER_LOCK_DEADLOCK
      errors which occur when multi-statement transaction encounters
      conflicting metadata lock in cases when waiting is possible.
      
      The idea is not to fail ER_LOCK_DEADLOCK error immediately when
      we encounter conflicting metadata lock. Instead we release all
      metadata locks acquired by current statement and start to wait
      until conflicting lock go away. To avoid deadlocks we use simple
      empiric which aborts waiting with ER_LOCK_DEADLOCK error if it
      turns out that somebody is waiting for metadata locks owned by
      this transaction.
      
      This patch also fixes bug #46273 "MySQL 5.4.4 new MDL: Bug#989
      is not fully fixed in case of ALTER".
      
      The bug was that concurrent execution of UPDATE or MULTI-UPDATE
      statement as a part of multi-statement transaction that already
      has used table being updated and ALTER TABLE statement might have
      resulted of loss of isolation between this transaction and ALTER
      TABLE statement, which manifested itself as changes performed by
      ALTER TABLE becoming visible in transaction and wrong binary log
      order as a consequence.
      
      This problem occurred when UPDATE or MULTI-UPDATE's wait in
      mysql_lock_tables() call was aborted due to metadata lock
      upgrade performed by concurrent ALTER TABLE. After such abort all
      metadata locks held by transaction were released but transaction
      silently continued to be executed as if nothing has happened.
      
      We solve this problem by changing our code not to release all
      locks in such case. Instead we release only locks which were
      acquired by current statement and then try to reacquire them
      by restarting open/lock tables process. We piggyback on simple
      deadlock detector implementation since this change has to be
      done anyway for it.
      236539b4
  14. 22 Dec, 2009 1 commit
    • Konstantin Osipov's avatar
      A prerequisite patch for the fix for Bug#46224 · 39a1a50d
      Konstantin Osipov authored
      "HANDLER statements within a transaction might lead to deadlocks".
      Introduce a notion of a sentinel to MDL_context. A sentinel
      is a ticket that separates all tickets in the context into two
      groups: before and after it. Currently we can have (and need) only
      one designated sentinel -- it separates all locks taken by LOCK
      TABLE or HANDLER statement, which must survive COMMIT and ROLLBACK
      and all other locks, which must be released at COMMIT or ROLLBACK.
      The tricky part is maintaining the sentinel up to date when
      someone release its corresponding ticket. This can happen, e.g.
      if someone issues DROP TABLE under LOCK TABLES (generally,
      see all calls to release_all_locks_for_name()).
      MDL_context::release_ticket() is modified to take care of it.
      
      ******
      A fix and a test case for Bug#46224 "HANDLER statements within a
      transaction might lead to deadlocks".
      
      An attempt to mix HANDLER SQL statements, which are transaction-
      agnostic, an open multi-statement transaction,
      and DDL against the involved tables (in a concurrent connection) 
      could lead to a deadlock. The deadlock would occur when
      HANDLER OPEN or HANDLER READ would have to wait on a conflicting
      metadata lock. If the connection that issued HANDLER statement
      also had other metadata locks (say, acquired in scope of a 
      transaction), a classical deadlock situation of mutual wait
      could occur.
      
      Incompatible change: entering LOCK TABLES mode automatically
      closes all open HANDLERs in the current connection.
      
      Incompatible change: previously an attempt to wait on a lock
      in a connection that has an open HANDLER statement could wait
      indefinitely/deadlock. After this patch, an error ER_LOCK_DEADLOCK
      is produced.
      
      The idea of the fix is to merge thd->handler_mdl_context
      with the main mdl_context of the connection, used for transactional
      locks. This makes deadlock detection possible, since all waits
      with locks are "visible" and available to analysis in a single
      MDL context of the connection.
      
      Since HANDLER locks and transactional locks have a different life
      cycle -- HANDLERs are explicitly open and closed, and so
      are HANDLER locks, explicitly acquired and released, whereas
      transactional locks "accumulate" till the end of a transaction
      and are released only with COMMIT, ROLLBACK and ROLLBACK TO SAVEPOINT,
      a concept of "sentinel" was introduced to MDL_context.
      All locks, HANDLER and others, reside in the same linked list.
      However, a selected element of the list separates locks with
      different life cycle. HANDLER locks always reside at the
      end of the list, after the sentinel. Transactional locks are
      prepended to the beginning of the list, before the sentinel.
      Thus, ROLLBACK, COMMIT or ROLLBACK TO SAVEPOINT, only
      release those locks that reside before the sentinel. HANDLER locks
      must be released explicitly as part of HANDLER CLOSE statement,
      or an implicit close. 
      The same approach with sentinel
      is also employed for LOCK TABLES locks. Since HANDLER and LOCK TABLES
      statement has never worked together, the implementation is
      made simple and only maintains one sentinel, which is used either
      for HANDLER locks, or for LOCK TABLES locks.
      39a1a50d
  15. 30 Nov, 2009 1 commit
    • Konstantin Osipov's avatar
      Initial import of WL#3726 "DDL locking for all metadata objects". · 69b9761f
      Konstantin Osipov authored
      Backport of:
      ------------------------------------------------------------
      revno: 2630.4.1
      committer: Dmitry Lenev <dlenev@mysql.com>
      branch nick: mysql-6.0-3726-w
      timestamp: Fri 2008-05-23 17:54:03 +0400
      message:
        WL#3726 "DDL locking for all metadata objects".
      
        After review fixes in progress.
      ------------------------------------------------------------
      
      This is the first patch in series. It transforms the metadata 
      locking subsystem to use a dedicated module (mdl.h,cc). No 
      significant changes in the locking protocol. 
      The import passes the test suite with the exception of 
      deprecated/removed 6.0 features, and MERGE tables. The latter
      are subject to a fix by WL#4144.
      Unfortunately, the original changeset comments got lost in a merge,
      thus this import has its own (largely insufficient) comments.
      
      This patch fixes Bug#25144 "replication / binlog with view breaks".
      Warning: this patch introduces an incompatible change:
      Under LOCK TABLES, it's no longer possible to FLUSH a table that 
      was not locked for WRITE.
      Under LOCK TABLES, it's no longer possible to DROP a table or
      VIEW that was not locked for WRITE.
      
      ******
      Backport of:
      ------------------------------------------------------------
      revno: 2630.4.2
      committer: Dmitry Lenev <dlenev@mysql.com>
      branch nick: mysql-6.0-3726-w
      timestamp: Sat 2008-05-24 14:03:45 +0400
      message:
        WL#3726 "DDL locking for all metadata objects".
      
        After review fixes in progress.
      
      ******
      Backport of:
      ------------------------------------------------------------
      revno: 2630.4.3
      committer: Dmitry Lenev <dlenev@mysql.com>
      branch nick: mysql-6.0-3726-w
      timestamp: Sat 2008-05-24 14:08:51 +0400
      message:
        WL#3726 "DDL locking for all metadata objects"
      
        Fixed failing Windows builds by adding mdl.cc to the lists
        of files needed to build server/libmysqld on Windows.
      
      ******
      Backport of:
      ------------------------------------------------------------
      revno: 2630.4.4
      committer: Dmitry Lenev <dlenev@mysql.com>
      branch nick: mysql-6.0-3726-w
      timestamp: Sat 2008-05-24 21:57:58 +0400
      message:
        WL#3726 "DDL locking for all metadata objects".
      
        Fix for assert failures in kill.test which occured when one
        tried to kill ALTER TABLE statement on merge table while it
        was waiting in wait_while_table_is_used() for other connections
        to close this table.
      
        These assert failures stemmed from the fact that cleanup code
        in this case assumed that temporary table representing new
        version of table was open with adding to THD::temporary_tables
        list while code which were opening this temporary table wasn't
        always fulfilling this.
      
        This patch changes code that opens new version of table to
        always do this linking in. It also streamlines cleanup process
        for cases when error occurs while we have new version of table
        open.
      
      ******
      WL#3726 "DDL locking for all metadata objects"
      Add libmysqld/mdl.cc to .bzrignore.
      ******
      Backport of:
      ------------------------------------------------------------
      revno: 2630.4.6
      committer: Dmitry Lenev <dlenev@mysql.com>
      branch nick: mysql-6.0-3726-w
      timestamp: Sun 2008-05-25 00:33:22 +0400
      message:
        WL#3726 "DDL locking for all metadata objects".
      
        Addition to the fix of assert failures in kill.test caused by
        changes for this worklog.
      
      
      Make sure we close the new table only once.
      69b9761f
  16. 22 Sep, 2009 1 commit
    • MySQL Build Team's avatar
      Backport into build-200909221805-5.1.37sp1 · 7d520f51
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 3075
      > revision-id: ramil@mysql.com-20090821055535-a5aeas33epokjjnp
      > parent: joro@sun.com-20090820141122-gq6eyozybvar4o4s
      > committer: Ramil Kalimullin <ramil@mysql.com>
      > branch nick: mysql-5.1-bugteam
      > timestamp: Fri 2009-08-21 10:55:35 +0500
      > message:
      >   Fix for bug #46456 [Ver->Prg]: HANDLER OPEN + TRUNCATE + DROP
      >   (temporary) TABLE, crash
      >   
      >   Problem: if one has an open "HANDLER t1", further "TRUNCATE t1" 
      >   doesn't close the handler and leaves handler table hash in an 
      >   inconsistent state, that may lead to a server crash.
      >   
      >   Fix: TRUNCATE should implicitly close all open handlers.
      >   
      >   Doc. request: the fact should be described in the manual accordingly.
      7d520f51
  17. 21 Aug, 2009 1 commit
    • Ramil Kalimullin's avatar
      Fix for bug #46456 [Ver->Prg]: HANDLER OPEN + TRUNCATE + DROP · f59400f4
      Ramil Kalimullin authored
      (temporary) TABLE, crash
      
      Problem: if one has an open "HANDLER t1", further "TRUNCATE t1" 
      doesn't close the handler and leaves handler table hash in an 
      inconsistent state, that may lead to a server crash.
      
      Fix: TRUNCATE should implicitly close all open handlers.
      
      Doc. request: the fact should be described in the manual accordingly.
      f59400f4
  18. 24 Jun, 2009 1 commit
    • MySQL Build Team's avatar
      Backport into build-200906240007-5.1.34sp1 · 5828d963
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 2857.1.8
      > revision-id: sergey.glukhov@sun.com-20090417084627-yvt63k51vvvjbx9j
      > parent: anurag.shekhar@sun.com-20090417055354-7vw80v1rwn0z1tt4
      > parent: sergey.glukhov@sun.com-20090417074115-dv9h5ijalj2hgq3r
      > committer: Sergey Glukhov <Sergey.Glukhov@sun.com>
      > branch nick: mysql-5.1-bugteam
      > timestamp: Fri 2009-04-17 13:46:27 +0500
      > message:
      >   5.0-bugteam->5.1-bugteam merge
      >     ------------------------------------------------------------
      >     revno: 1810.3882.12
      >     revision-id: sergey.glukhov@sun.com-20090417074115-dv9h5ijalj2hgq3r
      >     parent: patrick.crews@sun.com-20090416174744-u9fxu6ophud91a1h
      >     committer: Sergey Glukhov <Sergey.Glukhov@sun.com>
      >     branch nick: mysql-5.0-bugteam
      >     timestamp: Fri 2009-04-17 12:41:15 +0500
      >     message:
      >       Bug#44151 using handler commands on information_schema tables crashes server
      >       information schema tables are based on internal tmp tables which are removed
      >       after each statement execution. So HANDLER comands can not be used with
      >       information schema.
      5828d963
  19. 20 Nov, 2007 1 commit
    • davi@endora.local's avatar
      Bug#31397 Inconsistent drop table behavior of handler tables. · 94e6e4ff
      davi@endora.local authored
      The problem is that DROP TABLE and other DDL statements failed to
      automatically close handlers associated with tables that were marked
      for reopen (FLUSH TABLES).
      
      The current implementation fails to properly discard handlers of
      dropped tables (that were marked for reopen) because it searches
      on the open handler tables list and using the current alias of the
      table being dropped. The problem is that it must not use the open
      handler tables list to search because the table might have been
      closed (marked for reopen) by a flush tables command and also it
      must not use the current table alias at all since multiple different
      aliases may be associated with a single table. This is specially
      visible when a user has two open handlers (using alias) of a same
      table and a flush tables command is issued before the table is
      dropped (see test case). Scanning the handler table list is also
      useless for dropping handlers associated with temporary tables,
      because temporary tables are not kept in the THD::handler_tables
      list.
      
      The solution is to simple scan the handlers hash table searching
      for, and deleting all handlers with matching table names if the
      reopen flag is not passed to the flush function, indicating that
      the handlers should be deleted. All matching handlers are deleted
      even if the associated the table is not open.
      94e6e4ff
  20. 01 Nov, 2007 1 commit
    • davi@endora.local's avatar
      Bug#30882 Dropping a temporary table inside a stored function may cause a server crash · cc007acb
      davi@endora.local authored
      If a stored function that contains a drop temporary table statement
      is invoked by a create temporary table of the same name may cause
      a server crash. The problem is that when dropping a table no check
      is done to ensure that table is not being used by some outer query
      (or outer statement), potentially leaving the outer query with a
      reference to a stale (freed) table.
      
      The solution is when dropping a temporary table, always check if
      the table is being used by some outer statement as a temporary
      table can be dropped inside stored procedures.
      
      The check is performed by looking at the TABLE::query_id value for
      temporary tables. To simplify this check and to solve a bug related
      to handling of temporary tables in prelocked mode, this patch changes
      the way in which this member is used to track the fact that table is
      used/unused. Now we ensure that TABLE::query_id is zero for unused
      temporary tables (which means that all temporary tables which were
      used by a statement should be marked as free for reuse after it's
      execution has been completed).
      cc007acb
  21. 11 Oct, 2007 1 commit
  22. 10 Oct, 2007 1 commit
  23. 29 Aug, 2007 1 commit
  24. 16 Aug, 2006 2 commits
    • mleich@three.local.lan's avatar
      This changeset belongs to · 1a8c9130
      mleich@three.local.lan authored
              WL#3397 Refactoring storage engine test cases (for falcon)
            It contains fixes according to second code review.
      - Remove any occurence of hardcoded assignments of storage engines
      - Use variable names exact telling what it is used for
      - Updated comments
      - remove trailing spaces
      1a8c9130
    • mleich@three.local.lan's avatar
      This changeset belongs to · aaa9ed3e
      mleich@three.local.lan authored
            WL#3397 Refactoring storage engine test cases (for falcon)
          It contains also fixes according to code review.
          Contents: Testcases which were in history dedicated to InnoDB or MyISAM only.
          Modifications:
          1. Shift the main testing code into include/<testing field>.inc
             Introduce $variables which can be used to omit tests for features which are not supported by
             certain storage engines.
          2. The storage engine to be tested is assigned within the toplevel script (t/<whatever>_<engine>.test)
             via variable $engine_type and the the main testing code is sourced from 
             include/<testing field>.inc
          3. Some toplevel testscripts have to be renamed to
             - avoid immediate or future namespace clashes
             - show via filename which storage engine is tested
          4. Minor code cleanup like remove trailing spaces, some additional comments ....
      aaa9ed3e
  25. 05 Jan, 2006 1 commit
    • monty@mysql.com's avatar
      Review fixes of new pushed code · 6e22e29d
      monty@mysql.com authored
      - Fixed tests
      - Optimized new code
      - Fixed some unlikely core dumps
      - Better bug fixes for:
        - #14397 - OPTIMIZE TABLE with an open HANDLER causes a crash
        - #14850 (ERROR 1062 when a quering a view using a Group By on a column that can be null
      6e22e29d
  26. 15 Nov, 2005 1 commit
    • ingo@mysql.com's avatar
      Bug#14397 - OPTIMIZE TABLE with an open HANDLER causes a crash · 74781d65
      ingo@mysql.com authored
      Version for 5.0.
      It fixes three problems:
      1. The cause of the bug was that we did not check the table version for
       the HANDLER ... READ commands. We did not notice when a table was
       replaced by a new one. This can happen during ALTER TABLE, REPAIR
       TABLE, and OPTIMIZE TABLE (there might be more cases). I call the fix
       for this problem "the primary bug fix".
      2. mysql_ha_flush() was not always called with a locked LOCK_open.
       Though the function comment clearly said it must.
       I changed the code so that the locking is done when required. I call
       the fix for this problem "the secondary fix".
      3. In 5.0 (not in 4.1 or 4.0) DROP TABLE had a possible deadlock flaw in
       concur with FLUSH TABLES WITH READ LOCK. I call the fix for this
       problem "the 5.0 addendum fix".
      74781d65
  27. 03 Nov, 2005 1 commit
    • ingo@mysql.com's avatar
      Bug#14397 - OPTIMIZE TABLE with an open HANDLER causes a crash · 1b99d30c
      ingo@mysql.com authored
      Version for 4.0.
      It fixes two problems:
      1. The cause of the bug was that we did not check the table version for
         the HANDLER ... READ commands. We did not notice when a table was
         replaced by a new one. This can happen during ALTER TABLE, REPAIR
         TABLE, and OPTIMIZE TABLE (there might be more cases). I call the fix
         for this problem "the primary bug fix".
      2. mysql_ha_flush() was not always called with a locked LOCK_open.
         Though the function comment clearly said it must.
         I changed the code so that the locking is done when required. I call
         the fix for this problem "the secondary fix".
      1b99d30c
  28. 07 Oct, 2004 1 commit
    • monty@mysql.com's avatar
      After merge fixes · 6239edc1
      monty@mysql.com authored
      Some bigger code changes was necessary becasue of the multi-table-update and the new HANDLER code
      6239edc1
  29. 24 Sep, 2004 1 commit
    • ingo@mysql.com's avatar
      BUG#4286 - HANDLER tables are closed by FLUSH TABLE(S). · e47decfa
      ingo@mysql.com authored
      BUG#4335 - one name can be handler open'ed many times.
      Reworked the HANDLER functions and interface.
      Using a HASH to store information on open tables that
      survives FLUSH TABLE.
      HANDLER tables alias names must now be unique, though it
      is allowed in 4.0 to qualify them with the database name
      of the base table.
      e47decfa
  30. 16 Jun, 2004 1 commit
  31. 15 Jun, 2004 1 commit
  32. 18 May, 2004 1 commit
  33. 13 Jan, 2004 1 commit
  34. 16 Dec, 2003 1 commit
  35. 10 Dec, 2003 1 commit
  36. 18 Aug, 2003 1 commit
    • monty@mashka.mysql.fi's avatar
      After merge fixes · 4f751216
      monty@mashka.mysql.fi authored
      Use server character set if --default-character-set is not used
      Added convert_string() for more efficient alloc+character-set convert of strings
      4f751216
  37. 04 Jul, 2003 3 commits