1. 26 Jul, 2010 1 commit
  2. 23 Jul, 2010 1 commit
    • Jon Olav Hauglid's avatar
      Bug #55498 SHOW CREATE TRIGGER takes wrong type of metadata lock · 97bfd559
      Jon Olav Hauglid authored
      The first problem was that SHOW CREATE TRIGGER took a stronger metadata
      lock than required. This caused the statement to be blocked when it was
      not needed. For example, LOCK TABLE WRITE in one connection would block
      SHOW CREATE TRIGGER in another connection.
      
      Another problem was that a SHOW CREATE TRIGGER statement issued inside
      a transaction did not release its metadata locks at the end of the
      statement execution. This happened even if SHOW CREATE TRIGGER is an
      information statement. The consequence was that SHOW CREATE TRIGGER
      was able to block other connections from accessing the table
      (e.g. using ALTER TABLE).
      
      This patch fixes the problem by changing SHOW CREATE TRIGGER to take
      a MDL_SHARED_HIGH_PRIO metadata lock similar to what is already done
      for SHOW CREATE TABLE. The patch also changes SHOW CREATE TRIGGER to
      explicitly release any metadata locks taken by the statement after
      it completes.
      
      Test case added to show_check.test.
      97bfd559
  3. 22 Jul, 2010 3 commits
    • Davi Arnaut's avatar
    • Jon Olav Hauglid's avatar
      Bug #54905 Connection with WRITE lock cannot ALTER table due to · e814e9ac
      Jon Olav Hauglid authored
                 concurrent SHOW CREATE
      
      The problem was that a SHOW CREATE TABLE statement issued inside
      a transaction did not release its metadata locks at the end of the
      statement execution. This happened even if SHOW CREATE TABLE is an
      information statement. 
      
      The consequence was that SHOW CREATE TABLE was able to block other
      connections from accessing the table (e.g. using ALTER TABLE).
      
      This patch fixes the problem by explicitly releasing any metadata
      locks taken by SHOW CREATE TABLE after the statement completes.
      
      Test case added to show_check.test.
      e814e9ac
    • Jon Olav Hauglid's avatar
      Bug #55223 assert in Protocol::end_statement during CREATE DATABASE · 13109514
      Jon Olav Hauglid authored
      The problem was that a statement could cause an assert if it was aborted by
      KILL QUERY while it waited on a metadata lock. This assert checks that a
      statement either sends OK or an error to the client. If the bug was triggered
      on release builds, it caused OK to be sent to the client instead of
      ER_QUERY_INTERRUPTED.
      
      The root cause of the problem was that there are two separate ways to tell if a
      statement is killed: thd->killed and mysys_var->abort. KILL QUERY causes both
      to be set, thd->killed before mysys_var->abort. Also, both values are reset
      at the end of statement execution. This means that it is possible for
      KILL QUERY to first set thd->killed, then have the killed statement reset
      both thd->killed and mysys_var->abort and finally have KILL QUERY set
      mysys_var->abort. This means that the connection with the killed statement
      will start executing the next statement with the two values out of sync - i.e.
      thd->killed not set but mysys_var->abort set.
      
      Since mysys_var->abort is used to check if a wait for a metadata lock should
      be aborted, the next statement would immediately abort any such waiting.
      When waiting is aborted, no OK message is sent and thd->killed is checked to
      see if ER_QUERY_INTERRUPTED should be sent to the client. But since
      the->killed had been reset, neither OK nor an error message was sent to the
      client. This then triggered the assert.
      
      This patch fixes the problem by changing the metadata lock waiting code to
      check thd->killed.
      
      No test case added as reproducing the assert is dependent on very exact timing
      of two (or more) threads. The patch has been checked using RQG and the grammar
      posted on the bug report.
      13109514
  4. 19 Jul, 2010 1 commit
  5. 17 Jul, 2010 2 commits
  6. 16 Jul, 2010 20 commits
  7. 15 Jul, 2010 12 commits