1. 01 Jun, 2010 2 commits
  2. 30 May, 2010 3 commits
  3. 28 May, 2010 1 commit
    • Dmitry Lenev's avatar
      Patch that addresses bug #53976 "ALTER TABLE RENAME · 1fbdf160
      Dmitry Lenev authored
      is allowed on views (not documented, broken)".
      
      Remove support of ALTER TABLE RENAME for views as:
      a) this feature was not documented,
      c) does not add any compatibility with other databases,
      b) its implementation doesn't follow metadata locking
         protocol by accessing .FRM without holding any
         metadata lock,
      c) its implementation complicates ALTER TABLE's code
         by introducing  yet another separate branch to it.
      
      After this patch one can rename a view by using the
      documented way - RENAME TABLE statement.
      1fbdf160
  4. 27 May, 2010 3 commits
  5. 26 May, 2010 2 commits
    • Dmitry Lenev's avatar
      Fix for bug #53238 "mdl_sync fails sporadically". · 303fe45a
      Dmitry Lenev authored
      The problem was that mdl_sync.test was failing sporadically,
      due to fact that part of the test didn't take into account
      effects of MyISAM's concurrent insert.
      
      This patch solves the problem by making test case robust
      against concurrent insert.
      303fe45a
    • Dmitry Lenev's avatar
      Fix for bug #51263 "Deadlock between transactional · c070e5a1
      Dmitry Lenev authored
      SELECT and ALTER TABLE ...  REBUILD PARTITION".
      
      ALTER TABLE on InnoDB table (including partitioned tables)
      acquired exclusive locks on rows of table being altered.
      In cases when there was concurrent transaction which did
      locking reads from this table this sometimes led to a
      deadlock which was not detected by MDL subsystem nor by
      InnoDB engine (and was reported only after exceeding
      innodb_lock_wait_timeout).
      
      This problem stemmed from the fact that ALTER TABLE acquired
      TL_WRITE_ALLOW_READ lock on table being altered. This lock
      was interpreted as a write lock and thus for table being
      altered handler::external_lock() method was called with
      F_WRLCK as an argument. As result InnoDB engine treated
      ALTER TABLE as an operation which is going to change data
      and acquired LOCK_X locks on rows being read from old
      version of table.
      
      In case when there was a transaction which already acquired
      SR metadata lock on table and some LOCK_S locks on its rows
      (e.g. by using it in subquery of DML statement) concurrent
      ALTER TABLE was blocked at the moment when it tried to
      acquire LOCK_X lock before reading one of these rows.
      The transaction's attempt to acquire SW metadata lock on
      table being altered led to deadlock, since it had to wait
      for ALTER TABLE to release SNW lock. This deadlock was not
      detected and got resolved only after timeout expiring
      because waiting were happening in two different subsystems.
      
      Similar deadlocks could have occured in other situations.
      This patch tries to solve the problem by changing ALTER TABLE
      implementation to use TL_READ_NO_INSERT lock instead of
      TL_WRITE_ALLOW_READ. After this step handler::external_lock()
      is called with F_RDLCK as an argument and InnoDB engine
      correctly interprets ALTER TABLE as operation which only
      reads data from original version of table. Thanks to this
      ALTER TABLE acquires only LOCK_S locks on rows it reads.
      This, in its turn, causes inter-subsystem deadlocks to go
      away, as all potential lock conflicts and thus deadlocks will
      be limited to metadata locking subsystem:
      
      - When ALTER TABLE reads rows from table being altered it
        can't encounter any locks which conflict with LOCK_S row
        locks. There should be no concurrent transactions holding
        LOCK_X row locks. Such a transaction should have been
        acquired SW metadata lock on table first which would have
        conflicted with ALTER's SNW lock.
      - Vice versa, when DML which runs concurrently with ALTER
        TABLE tries to lock row it should be requesting only LOCK_S
        lock which is compatible with locks acquired by ALTER,
        as otherwise such DML must own an SW metadata lock on table
        which would be incompatible with ALTER's SNW lock.
      c070e5a1
  6. 25 May, 2010 2 commits
    • Davi Arnaut's avatar
      Bug#42643: InnoDB does not support replication of TRUNCATE TABLE · 3c279d9a
      Davi Arnaut authored
      The problem was that TRUNCATE TABLE didn't take a exclusive
      lock on a table if it resorted to truncating via delete of
      all rows in the table. Specifically for InnoDB tables, this
      could break proper isolation as InnoDB ends up aborting some
      granted locks when truncating a table.
      
      The solution is to take a exclusive metadata lock before
      TRUNCATE TABLE can proceed. This guarantees that no other
      transaction is using the table.
      
      Incompatible change: Truncate via delete no longer fails
      if sql_safe_updates is activated (this was a undocumented
      side effect).
      3c279d9a
    • Dmitry Lenev's avatar
      Pre-requisite patch for bug #51263 "Deadlock between · a3c080be
      Dmitry Lenev authored
      transactional SELECT and ALTER TABLE ... REBUILD PARTITION".
      
      The goal of this patch is to decouple type of metadata
      lock acquired for table by open_tables() from type of
      table-level lock to be acquired on it.
      
      To achieve this we change approach to how we determine what
      type of metadata lock should be acquired on table to be open.
      Now instead of inferring it at open_tables() time from flags
      and type of table-level lock we rely on that type of metadata
      lock is properly set at parsing time and is not changed
      further.
      a3c080be
  7. 21 May, 2010 1 commit
    • Dmitry Lenev's avatar
      Follow-up for the fix for bug #46947 "Embedded SELECT without · 6ceacd4f
      Dmitry Lenev authored
      FOR UPDATE is causing a lock".
       
      This patch tries to address problems which were exposed 
      during backporting of original patch to 5.1 tree.
       
      - It ensures that we don't change locking behavior of simple
        SELECT statements on InnoDB tables when they are executed
        under LOCK TABLES ... READ and with @@innodb_table_locks=0.
        Also we no longer pass TL_READ_DEFAULT/TL_WRITE_DEFAULT 
        lock types, which are supposed to be parser-only, to 
        handler::start_stmt() method.
      - It makes check_/no_concurrent_insert.inc auxiliary scripts 
        more robust against changes in test cases that use them
        and also ensures that they don't unnecessarily change 
        environment of caller.
      6ceacd4f
  8. 19 May, 2010 1 commit
    • Jon Olav Hauglid's avatar
      Bug #53798 OPTIMIZE TABLE breaks repeatable read · c09eb2af
      Jon Olav Hauglid authored
      The problem was that OPTMIZE TABLE was allowed to run on a table
      in use by a transaction in a different connection. This caused
      repeatable read to break.
      
      This bug was fixed by the introduction of metadata locking, WL#4284.
      OPTIMIZE TABLE will now be blocked until the transaction using the
      table, has ended.
      
      This patch contains a regression test added to innodb_mysql_lock.test
      and no code changes.
      c09eb2af
  9. 18 May, 2010 3 commits
  10. 17 May, 2010 2 commits
  11. 16 May, 2010 2 commits
  12. 14 May, 2010 3 commits
    • Alexander Nozdrin's avatar
      Patch for Bug#27863 (excessive memory usage for many small queries in a · 5c4333bc
      Alexander Nozdrin authored
      multiquery packet).
      
      Background:
      
        - a query can contain multiple SQL statements;
      
        - the server frees resources allocated to process a query when the
          whole query is handled. In other words, resources allocated to process
          one SQL statement from a multi-statement query are freed when all SQL
          statements are handled.
      
      The problem was that the parser allocated a buffer of size of the whole
      query for each SQL statement in a multi-statement query. Thus, if a query
      had many SQL-statements (so, the query was long), but each SQL statement
      was short, ther parser tried to allocate huge amount of memory (number of
      small SQL statements * length of the whole query).
      
      The memory was allocated for a so-called "cpp buffer", which is intended to
      store pre-processed SQL statement -- SQL text without version specific
      comments.
      
      The fix is to allocate memory for the "cpp buffer" once for all SQL
      statements (once for a query).
      5c4333bc
    • Konstantin Osipov's avatar
      Committing on behalf of Valdislav Vaintroub (reviewed and · d63caa0c
      Konstantin Osipov authored
      approved):
      
      3161 Vladislav Vaintroub       2010-04-29                 
       Bug#53196 : CMake builds don't support 'make tags' and 
      'make ctags' targets.  
         - Added tags and ctags targets
      d63caa0c
    • Alexander Nozdrin's avatar
      Patch for Bug#21818 (Return value of ROW_COUNT() is incorrect · 7752ccec
      Alexander Nozdrin authored
      for ALTER TABLE, LOAD DATA).
      
      ROW_COUNT is now assigned according to the following rules:
      
        - In my_ok():
          - for DML statements: to the number of affected rows;
          - for DDL statements: to 0.
      
        - In my_eof(): to -1 to indicate that there was a result set.
      
          We derive this semantics from the JDBC specification, where int
          java.sql.Statement.getUpdateCount() is defined to (sic) "return the
          current result as an update count; if the result is a ResultSet
          object or there are no more results, -1 is returned".
      
        - In my_error(): to -1 to be compatible with the MySQL C API and
          MySQL ODBC driver.
      
        - For SIGNAL statements: to 0 per WL#2110 specification. Zero is used
          since that's the "default" value of ROW_COUNT in the diagnostics area.
      7752ccec
  13. 13 May, 2010 3 commits
  14. 12 May, 2010 4 commits
    • Jonathan Perkin's avatar
    • Jonathan Perkin's avatar
      Remove comments. · 9d33e954
      Jonathan Perkin authored
      9d33e954
    • Jonathan Perkin's avatar
      Changes to build using CMake according to existing release packages: · 5b85121c
      Jonathan Perkin authored
       - Update/fix file layouts for each package type, add new types for
         native package formats including deb, rpm and svr4.
      
       - Build all plugins, including debug versions
      
       - Update compiler flags to match current release
      
       - Add missing @VAR@ expansions
      
       - Install correct mysqclient library symlinks
      
       - Fix icc/ia64 builds
      
       - Fix install of libmysqld-debug
      
       - Don't include mysql_embedded
      
       - Remove unpackaged manual pages to avoid missing files warnings
      
       - Don't install mtr's test suite
      5b85121c
    • Jonathan Perkin's avatar
      Large number of changes to support building RPMs using CMake, along · cb327fd8
      Jonathan Perkin authored
      with other merges from the old distribution-specific spec file.
      
       - update copyright notices
      
       - remove __os_install_post override, it was only necessary as a
         hack to build debuginfo packages - now that we no longer make
         them we can revert to the distribution macro which likely has
         other useful bits we might want
      
       - remove _unpackaged_files_terminate_build override, we want to
         know of any orphaned files
      
       - include native distribution support
      
       - no longer build separate debuginfo RPMs, instead just include
         debug/symbols in all binaries, which is more useful for support
      
       - include support for building commercial RPMs, requires a
         commercial source tree
      
       - remove cluster RPM support, we don't build them from this
         source tree
      
       - use CMake for building, and update package lists to match the
         new install layout/files.  Remove any options which were only
         useful for automake builds (e.g. yassl/zlib).
      
       - other minor cleanups
      cb327fd8
  15. 11 May, 2010 2 commits
  16. 07 May, 2010 2 commits
  17. 05 May, 2010 4 commits
    • Konstantin Osipov's avatar
      Clean-up, give better names, add comments to · cca59e83
      Konstantin Osipov authored
      thd->in_multi_stmt_transaction() and thd->active_transaction().
      cca59e83
    • Magne Mahre's avatar
      Bug#49193 CREATE TABLE reacts differently depending on whether · 24a14875
      Magne Mahre authored
                data is selected or not
      
      Temporary and permanent tables should live in different 
      namespaces.  In this case, resolving a permanent table
      name gave the temporary table, resulting in a name
      collision.
      24a14875
    • Alexander Nozdrin's avatar
      Patch for Bug#50511 (Sometimes wrong handling of user variables containing NULL). · d91c271b
      Alexander Nozdrin authored
            
      The bug happened under the following condition:
        - there was a user variable of type REAL, containing NULL value
        - there was a table with a NOT_NULL column of any type but REAL, having
          default value (or auto increment);
        - a row was inserted into the table with the user variable as value.
          A warning was emitted here.
      
      The problem was that handling of NULL values of REAL type was not properly
      implemented: it didn't expect that REAL NULL value can be assigned to other
      data type.
      
      Basically, the problem was that set_field_to_null() was used instead of
      set_field_to_null_with_conversions().
      
      The fix is to use the right function, or more generally, to allow conversion of
      REAL NULL values to other data types.
      d91c271b
    • Alexander Barkov's avatar
      Bug#51571 load xml infile causes server crash · 25d31b8f
      Alexander Barkov authored
        
        Problem:
        item->name was NULL for Item_user_var_as_out_param
        which made strcmp(something, item->name) crash in the LOAD XML code.
        
        Fix:
        - item_func.h: Adding set_name() in constuctor for Item_user_var_as_out_param
        - sql_load.cc: Changing the condition in write_execute_load_query_log_event() which
        distiguished between Item_user_var_as_out_param and Item_field
        from
          if (item->name == NULL)
        to
          if (item->type() == Item::FIELD_ITEM)
        - loadxml.result, loadxml.test: adding tests
      25d31b8f