1. 30 May, 2010 2 commits
  2. 28 May, 2010 1 commit
    • Dmitry Lenev's avatar
      Patch that addresses bug #53976 "ALTER TABLE RENAME · 29db56ff
      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.
      
      mysql-test/r/rename.result:
        Adjusted existing test case for bug #14959 "ALTER TABLE isn't
        able to rename a view" after fixing bug #53976: "ALTER TABLE
        RENAME is allowed on views (not documented, broken)".
      mysql-test/r/view.result:
        Adjusted test case after removing support for renaming
        of views through ALTER TABLE ... RENAME.
      mysql-test/t/rename.test:
        Adjusted existing test case for bug #14959 "ALTER TABLE isn't
        able to rename a view" after fixing bug #53976: "ALTER TABLE
        RENAME is allowed on views (not documented, broken)".
      mysql-test/t/view.test:
        Adjusted test case after removing support for renaming
        of views through ALTER TABLE ... RENAME.
      sql/sql_table.cc:
        Removed support for ALTER TABLE ... RENAME for views.
        This feature was not properly documented and its
        implementation was not following metadata locking
        protocol.
      29db56ff
  3. 27 May, 2010 3 commits
    • Davi Arnaut's avatar
      Fix type mismatch. Table names are represented as LEX_STRING · de59f9bd
      Davi Arnaut authored
      objects whose length is stored in a size_t type.
      de59f9bd
    • Davi Arnaut's avatar
      Bug#42643: InnoDB does not support replication of TRUNCATE TABLE · b3ea6740
      Davi Arnaut authored
      Post-merge fix: Pass the right parameter type to open_and_lock_tables.
      Passing FALSE ensures that derived table handling is disabled, truncate
      only operates on base tables.
      
      sql/sql_truncate.cc:
        Pass FALSE to disable derived table handling. This was probably
        reminiscent of the use of open_n_lock_single_table, which
        can't be used as in some cases (e.g. merge) more than one
        table will be opened.
      sql/sql_truncate.h:
        TABLE_LIST is a struct.
      b3ea6740
    • Davi Arnaut's avatar
      Bug#42643: InnoDB does not support replication of TRUNCATE TABLE · c57b2f50
      Davi Arnaut authored
      Post-merge fix: Retrieve handler statistics to workaround quirks
      of the archive storage engine.
      
      mysql-test/t/archive.test:
        Add test case.
      sql/sql_truncate.cc:
        Call info method with has side-effects related to the archive
        storage engine. It will cause rows to become visible, allowing
        a error to be thrown once we attempt to delete the rows.
      c57b2f50
  4. 26 May, 2010 2 commits
    • Dmitry Lenev's avatar
      Fix for bug #53238 "mdl_sync fails sporadically". · b9a851d4
      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.
      b9a851d4
    • Dmitry Lenev's avatar
      Fix for bug #51263 "Deadlock between transactional · fe355a0f
      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.
      
      mysql-test/r/innodb_mysql_lock2.result:
        Added test for bug #51263 "Deadlock between transactional
        SELECT and ALTER TABLE ... REBUILD PARTITION".
      mysql-test/suite/rpl_ndb/r/rpl_ndb_binlog_format_errors.result:
        Since CREATE TRIGGER no longer acquires write lock on table
        it is no longer interpreted as an operation which modifies
        table data and therefore no longer fails if invoked for
        SBR-only engine in ROW mode.
      mysql-test/suite/rpl_ndb/t/rpl_ndb_binlog_format_errors.test:
        Since CREATE TRIGGER no longer acquires write lock on table
        it is no longer interpreted as an operation which modifies
        table data and therefore no longer fails if invoked for
        SBR-only engine in ROW mode.
      mysql-test/t/innodb_mysql_lock2.test:
        Added test for bug #51263 "Deadlock between transactional
        SELECT and ALTER TABLE ... REBUILD PARTITION".
      sql/ha_partition.cc:
        When ALTER TABLE creates a new partition to be filled from
        other partition lock it in F_WRLCK mode instead of using
        mode which was used for locking the whole table (it is
        F_RDLCK now).
      sql/lock.cc:
        Replaced conditions which used TL_WRITE_ALLOW_READ
        lock type with equivalent conditions using
        TL_WRITE_ALLOW_WRITE. This should allow to get rid
        of TL_WRITE_ALLOW_READ lock type eventually.
      sql/mdl.cc:
        Updated outdated comment to reflect current situation.
      sql/sql_base.cc:
        Replaced conditions which used TL_WRITE_ALLOW_READ
        lock type with equivalent conditions using
        TL_WRITE_ALLOW_WRITE. This should allow to get rid
        of TL_WRITE_ALLOW_READ lock type eventually.
      sql/sql_table.cc:
        mysql_admin_table():
          Use TL_WRITE_ALLOW_WRITE lock type instead of
          TL_WRITE_ALLOW_READ to determine that we need to acquire
          upgradable metadata lock. This should allow to completely
          get rid of TL_WRITE_ALLOW_READ in long term.
        mysql_recreate_table():
          ALTER TABLE now requires TL_READ_NO_INSERT thr_lock.c lock
          instead of TL_WRITE_ALLOW_READ.
      sql/sql_trigger.cc:
        Changed CREATE/DROP TRIGGER implementation to use
        TL_READ_NO_INSERT lock instead of TL_WRITE_ALLOW_READ lock.
        The latter is no longer necessary since:
        a) We now can rely on metadata locks to achieve proper
           isolation between two DDL statements or DDL and DML
           statements.
        b) This statement does not change any data in table so there
           is no need to inform storage engine about it.
      sql/sql_yacc.yy:
        Changed implementation of ALTER TABLE (and CREATE/DROP INDEX
        as a consequence) to use TL_READ_NO_INSERT lock instead of
        TL_WRITE_ALLOW_READ lock. This is possible since:
        a) We now can rely on metadata locks to achieve proper
           isolation between two DDL statements or DDL and DML
           statements.
        b) This statement only reads data in table being open.
           We write data only to the new version of table and
           then replace with it old version of table under
           X metadata lock.
        
        Thanks to this change InnoDB will no longer acquire LOCK_X
        locks on rows being read by ALTER TABLE (instead LOCK_S
        locks will be acquired) and thus cause of bug #51263
        "Deadlock between transactional SELECT and ALTER TABLE ...
        REBUILD PARTITION" is removed.
        
        Did the similar change for CREATE TRIGGER (see comments
        for sql_trigger.cc for details).
      fe355a0f
  5. 25 May, 2010 2 commits
    • Davi Arnaut's avatar
      Bug#42643: InnoDB does not support replication of TRUNCATE TABLE · 2f70065b
      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).
      
      libmysqld/CMakeLists.txt:
        Add new files to the build list.
      libmysqld/Makefile.am:
        Add new files to the build list.
      mysql-test/extra/binlog_tests/binlog_truncate.test:
        Add test case for Bug#42643
      mysql-test/include/mix1.inc:
        Update test case as TRUNCATE TABLE now grabs a exclusive lock.
        Ensure that TRUNCATE waits for granted locks on the table.
      mysql-test/suite/binlog/t/binlog_truncate_innodb.test:
        As with other data modifying statements, TRUNCATE is still not
        possible in a transaction with isolation level READ COMMITTED
        or READ UNCOMMITED. It would be possible to implement so, but
        it is not worth the effort.
      mysql-test/suite/binlog/t/binlog_truncate_myisam.test:
        Test under different binlog formats.
      mysql-test/suite/binlog/t/disabled.def:
        Re-enable test case.
      mysql-test/t/innodb_bug38231.test:
        Truncate no longer works with row-level locks.
      mysql-test/t/mdl_sync.test:
        Ensure that a acquired lock is not given up due to a conflict.
      mysql-test/t/partition_innodb_semi_consistent.test:
        End transaction as to release metadata locks.
      mysql-test/t/truncate.test:
        A metadata lock is now taken before the object is verified.
      sql/CMakeLists.txt:
        Add new files to the build list.
      sql/Makefile.am:
        Add new files to the build list.
      sql/datadict.cc:
        Introduce a new file specific for data dictionary operations.
      sql/datadict.h:
        Add header file.
      sql/sql_base.cc:
        Rename data dictionary function.
      sql/sql_bitmap.h:
        Include dependency.
      sql/sql_delete.cc:
        Move away from relying on mysql_delete() to delete all rows of
        a table. Thus, move any bits related to truncate to sql_truncate.cc
      sql/sql_delete.h:
        Remove parameter.
      sql/sql_parse.cc:
        Add protection against the global read lock -- a intention
        exclusive lock can be acquired in the truncate path.
      sql/sql_show.cc:
        Add sync point for testing scenarios where a pending flush
        is ignored.
      sql/sql_truncate.cc:
        Acquire a shared metadata lock before accessing table metadata.
        Upgrade the lock to a exclusive one if the table can be re-created.
        Rework binlog rules to better reflect the requirements.
      sql/sql_yacc.yy:
        Set appropriate lock types for table to be truncated.
      sql/table.h:
        Move to data dictionary header.
      2f70065b
    • Dmitry Lenev's avatar
      Pre-requisite patch for bug #51263 "Deadlock between · 6c09fabf
      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.
      
      sql/ha_ndbcluster.cc:
        Now one needs to properly initialize table list element's
        MDL_request object before calling mysql_rm_table_part2().
      sql/lock.cc:
        lock_table_names() no longer initializes table list elements'
        MDL_request objects. Now proper initialization of these
        requests is a responsibility of the caller.
      sql/lock.h:
        Removed MYSQL_OPEN_TAKE_UPGRADABLE_MDL flag which became
        unnecessary. Thanks to the fact that we don't reset type of
        requests for metadata locks between re-executions we now can
        figure out that upgradable locks are requested by simply
        looking at their type which were set in the parser. As result
        this flag became redundant.
      sql/mdl.h:
        Added version of new operator which simplifies allocation of
        MDL_request objects on a MEM_ROOT.
      sql/sp_head.cc:
        Added comment explaining why it is OK to infer type of
        metadata lock to request from type of table-level lock
        for prelocking.
        Added enum_mdl_type argument to sp_add_to_query_tables()
        to simplify its usage in trigger implementation.
      sql/sp_head.h:
        Added enum_mdl_type argument to sp_add_to_query_tables()
        to simplify its usage in trigger implementation.
      sql/sql_base.cc:
        - open_table_get_mdl_lock():
          Preserve type of MDL_request for table list element which
          was set in the parser by creating MDL_request objects on
          memory root if MYSQL_OPEN_FORCE_SHARED_MDL or
          MYSQL_OPEN_FORCE_SHARED_HIGH_PRIO_MDL flag were specified.
          Thanks to this and to the fact that we no longer reset
          type of requests for metadata locks between re-executions
          we no longer need to acquire exclusive metadata lock on
          table to be created in a special way. This lock is acquired
          by code handling acquiring of upgradable locks.
          Also changed signature/calling convention for this function
          to simplify its usage.
        - Accordingly special lock strategy for table list elements
          which was used for such locks became unnecessary and was
          removed. Other strategies were renamed.
        - Since we no longer have guarantee that MDL_request object
          which were not satisfied due to lock conflict belongs to
          table list element Open_table_context class and its methods
          were extended to remember pointer to MDL_request which has
          caused problem at request_backoff_action() time and use it
          in recover_from_failed_open(). Similar approach is used
          for cases when problem from which we need to recover is
          not related to MDL but to the table itself. In this case
          we store pointer to the element of table list.
        - Changed open_tables()/open_tables_check_upgradable_mdl()/
          open_tables_acquire_upgradable_mdl() not to rely on
          MYSQL_OPEN_TAKE_UPGRADABLE_MDL flag to understand when
          upgradable metadata locks should be acquired and not to
          infer type of MDL lock from type of table-level lock.
          Instead we assume that type of MDL to be acquired was set
          in the parser (we can do this as type of MDL_request is
          no longer reset between re-executions).
      sql/sql_class.h:
        Since we no longer have guarantee that MDL_request object
        which were not satisfied due to lock conflict belongs to
        table list element Open_table_context class and its methods
        were extended to remember pointer to MDL_request which has
        caused problem at request_backoff_action() time and use it
        in recover_from_failed_open(). Similar approach is used
        for cases when problem from which we need to recover is
        not related to MDL but to the table itself. In this case
        we store pointer to the element of table list.
      sql/sql_db.cc:
        Now one needs to properly initialize table list element's
        MDL_request object before calling mysql_rm_table_part2()
        or mysql_rename_tables().
      sql/sql_lex.cc:
        st_select_lex/st_select_lex_node::add_table_to_list() method
        now has argument which allows specify type of metadata lock
        to be requested for table list element being added.
      sql/sql_lex.h:
        - st_select_lex/st_select_lex_node::add_table_to_list()
          method now has argument which specifies type of metadata
          lock to be requested for table list element being added.
          This allows to explicitly set type of MDL lock to be
          acquired for a DDL statement in parser. It is also more
          future-proof than inferring type of MDL request from type
          of table-level lock.
        - Added Yacc_state::m_mdl_type member which specifies which
          type of metadata lock should be requested for tables to be
          added to table list by a grammar rule in cases when the same
          rule is used in several statements requiring different kinds
          of metadata locks.
      sql/sql_parse.cc:
        - st_select_lex::add_table_to_list() method now has argument
          which specifies type of metadata lock to be requested for
          table list element being added. This allows to explicitly
          set type of MDL lock to be acquired for a DDL statement in
          parser. It is also more future-proof than inferring type of
          MDL request from type of table-level lock.
        - EXCLUSIVE_DOWNGRADABLE_MDL lock strategy has a new name -
          OTLS_DOWNGRADE_IF_EXISTS.
        - Adjusted LOCK TABLES implementation to the fact that we no
          longer infer type of metadata lock to be acquired from table
          level lock and that type of MDL request is set at parsing.
          And thus MYSQL_OPEN_TAKE_UPGRADABLE_MDL flag became
          unnecessary.
      sql/sql_prepare.cc:
        TABLE_LIST's lock strategy SHARED_MDL was renamed to OTLS_NONE
        as now it means that metadata lock should not be changed during
        call to open_table() (if it has been already acquired) and is
        also used for exclusive metadata lock.
      sql/sql_show.cc:
        st_select_lex::add_table_to_list() method now has argument
        which specifies type of metadata lock to be requested for
        table list element being added.
      sql/sql_table.cc:
        - Adjusted mysql_admin_table()'s code to the fact that
          open_tables() no longer determines what kind of metadata
          lock should be obtained basing on type of table-level
          lock and flags. Instead type of metadata lock for table
          to be open should be set before calling open_tables().
        - Changed mysql_alter_table() code to the facts:
          a) that now it is responsibility of caller to properly
          initalize MDL_request in table list elements before calling
          lock_table_names()
          b) and that MYSQL_OPEN_TAKE_UPGRADABLE_MDL is no longer
          necessary since type of metadata lock to be obtained
          at open_tables() time is set during parsing.
        - Changed code of mysql_recreate_table() to properly set
          type of metadata and table-level lock to be obtained
          by mysql_alter_table() which it calls.
      sql/sql_trigger.cc:
        Instead of relying on MYSQL_OPEN_TAKE_UPGRADABLE_MDL flag to
        force open_tables() to take an upgradable lock we now specify
        exact type of lock to be taken when constructing table list
        element for table to be open for CREATE/DROP TRIGGER.
      sql/sql_view.cc:
        We no longer use TABLE_LIST::EXCLUSIVE_MDL strategy to force
        open_tables() to take an exclusive metadata lock on view to
        be created. Instead we rely on parser setting proper type of
        metadata lock to request and open_tables() acquiring it.
        This became possible thanks to the fact that we no longer
        reset type of MDL_request between statement re-executions.
      sql/sql_yacc.yy:
        Instead of inferring type of MDL_request for table to be
        open from type of table-level lock and flags passed to
        open_tables() we now explicitly specify them at parsing.
        This became possible thanks to the fact that we no longer
        reset type of MDL_request between statement re-executions.
        In future this should allow to decouple type of metadata
        lock from type of table-level lock.
        The only exception to this approach is statements implemented
        through mysql_admin_table() which re-uses same table list
        element several times with different types of table-level
        and metadata locks.
        We now also properly initialize MDL_request objects for table
        list elements which are later passed to lock_table_names()
        function.
      sql/table.cc:
        Do not reset type of MDL_request between statement
        re-executions. This became unnecessesary as we no longer
        change type of MDL_request residing in table list element.
        In its turn this change allows to set type of MDL_request
        only once - at parsing time.
      sql/table.h:
        Got rid of TABLE_LIST::EXCLUSIVE_MDL lock strategy.
        Now we can specify that we need to acquire exclusive lock
        on table to be processed by open_tables() through setting
        an appropriate type of MDL_request at parsing time (this
        became possible thanks to the fact that we no longer reset
        types of MDL_request's belonging to table list elements
        between statement re-execution).
        Strategy SHARED_MDL was renamed to OTLS_NONE as now it
        means that metadata lock should not be changed during call
        to open_table() (if it has been already acquired) and is
        also used for exclusive metadata lock.
        Strategy EXCLUSIVE_DOWNGRADABLE_MDL was renamed to
        OTLS_DOWNGRADE_IF_EXISTS.
      6c09fabf
  6. 21 May, 2010 1 commit
    • Dmitry Lenev's avatar
      Follow-up for the fix for bug #46947 "Embedded SELECT without · 5af3b013
      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.
      
      mysql-test/include/check_concurrent_insert.inc:
        Reset DEBUG_SYNC facility before and after using it in
        auxiliary script. This makes this script more robust against
        changes in test cases calling it. It also ensures that script
        does not unnecessarily change environment of caller.
      mysql-test/include/check_no_concurrent_insert.inc:
        Reset DEBUG_SYNC facility before and after using it in
        auxiliary script. This makes this script more robust against
        changes in test cases calling it. It also ensures that script
        does not unnecessarily change environment of caller.
      mysql-test/r/innodb-lock.result:
        Added coverage for LOCK TABLES ... READ behavior in
        @@innodb_table_locks = 0 mode. This test also checks
        that an appropriate type of lock is passed to
        handler::start_stmt() method.
      mysql-test/t/innodb-lock.test:
        Added coverage for LOCK TABLES ... READ behavior in
        @@innodb_table_locks = 0 mode. This test also checks
        that an appropriate type of lock is passed to
        handler::start_stmt() method.
      sql/sql_base.cc:
        Since we no longer set TL_READ as lock type for tables used  
        in simple SELECT right in the parser, in order to preserve  
        behavior for such statements on InnoDB tables when in  
        LOCK TABLES mode with @innodb_table_locks = 0,  
        check_lock_and_start_stmt() had to be changed to convert  
        TL_READ_DEFAULT to an appropriate type of read lock before  
        passing it to handler::start_stmt() method.  
        We do similar thing for TL_WRITE_DEFAULT as this lock type  
        is also supposed to be parser-only type.  
        As consequence read_lock_type_for_table() had to be  
        adjusted to behave properly when it is called from  
        check_lock_and_start_stmt() in prelocked mode.
      5af3b013
  7. 19 May, 2010 1 commit
    • Jon Olav Hauglid's avatar
      Bug #53798 OPTIMIZE TABLE breaks repeatable read · e7e5118f
      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.
      e7e5118f
  8. 18 May, 2010 3 commits
  9. 17 May, 2010 2 commits
  10. 16 May, 2010 2 commits
  11. 14 May, 2010 3 commits
    • Alexander Nozdrin's avatar
      Patch for Bug#27863 (excessive memory usage for many small queries in a · 571f62ee
      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).
      571f62ee
    • Konstantin Osipov's avatar
      Committing on behalf of Valdislav Vaintroub (reviewed and · ac2c6ba1
      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
      
      
      CMakeLists.txt:
        Add tags and ctags targets.
      cmake/Makefile.am:
        Add a cmake file to build tags.
      cmake/tags.cmake:
        Build tags and ctags.
      ac2c6ba1
    • Alexander Nozdrin's avatar
      Patch for Bug#21818 (Return value of ROW_COUNT() is incorrect · c3ea9d9c
      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.
      
      sql/protocol.cc:
        Fix a typo.
      sql/sql_class.h:
        - Introduce THD::get_row_count_func() / THD::set_row_count_func();
        - Remove the CF_HAS_ROW_COUNT define
      sql/sql_parse.cc:
        CF_HAS_ROW_COUNT was eliminated.
      c3ea9d9c
  12. 13 May, 2010 3 commits
  13. 12 May, 2010 4 commits
    • Jonathan Perkin's avatar
    • Jonathan Perkin's avatar
      Remove comments. · 4d3863ea
      Jonathan Perkin authored
      4d3863ea
    • Jonathan Perkin's avatar
      Changes to build using CMake according to existing release packages: · c4146a6b
      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
      c4146a6b
    • Jonathan Perkin's avatar
      Large number of changes to support building RPMs using CMake, along · aefea68f
      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
      aefea68f
  14. 11 May, 2010 2 commits
  15. 07 May, 2010 2 commits
  16. 05 May, 2010 7 commits
    • Konstantin Osipov's avatar
      Clean-up, give better names, add comments to · 25d83b75
      Konstantin Osipov authored
      thd->in_multi_stmt_transaction() and thd->active_transaction().
      
      
      include/mysql_com.h:
        Comment SERVER_STATUS_IN_TRANS flag.
      sql/ha_ndbcluster.cc:
        Rename: thd->in_multi_stmt_transaction() -> 
        thd->in_multi_stmt_transaction_mode().
      sql/handler.cc:
        Add comments.
      sql/log.cc:
        Rename: thd->in_multi_stmt_transaction() -> 
        thd->in_multi_stmt_transaction_mode().
      sql/log_event.cc:
        Rename: thd->in_multi_stmt_transaction() -> 
        thd->in_multi_stmt_transaction_mode().
      sql/sql_base.cc:
        Rename: thd->in_multi_stmt_transaction() -> 
        thd->in_multi_stmt_transaction_mode().
      sql/sql_cache.cc:
        Rename: thd->active_transaction() ->
        thd->in_active_multi_stmt_transaction().
      sql/sql_class.cc:
        Rename: thd->in_multi_stmt_transaction() -> 
        thd->in_multi_stmt_transaction_mode().
      sql/sql_class.h:
        Rename and comment two transaction processing- related methods.
      sql/sql_parse.cc:
        Rename: thd->in_multi_stmt_transaction() -> 
        thd->in_multi_stmt_transaction_mode().
        Rename: thd->active_transaction() ->
        thd->in_active_multi_stmt_transaction().
      sql/sql_prepare.cc:
        Rename: thd->in_multi_stmt_transaction() -> 
        thd->in_multi_stmt_transaction_mode().
      sql/sql_rename.cc:
        Rename: thd->active_transaction() ->
        thd->in_active_multi_stmt_transaction().
      sql/sql_table.cc:
        Rename: thd->active_transaction() ->
        thd->in_active_multi_stmt_transaction().
      sql/sys_vars.cc:
        Rename: thd->active_transaction() ->
        thd->in_active_multi_stmt_transaction().
      sql/transaction.cc:
        Rename: thd->in_multi_stmt_transaction() -> 
        thd->in_multi_stmt_transaction_mode().
        Rename: thd->active_transaction() ->
        thd->in_active_multi_stmt_transaction().
      25d83b75
    • Magne Mahre's avatar
      Bug#49193 CREATE TABLE reacts differently depending on whether · c9f32d90
      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.
      c9f32d90
    • Alexander Nozdrin's avatar
      Patch for Bug#50511 (Sometimes wrong handling of user variables containing NULL). · 11dcb13c
      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.
      11dcb13c
    • Alexander Barkov's avatar
      Bug#51571 load xml infile causes server crash · f311e6f0
      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
      f311e6f0
    • Magne Mahre's avatar
      Bug#48800 CREATE TABLE t...SELECT fails if t is a temporary · e8b0dc70
      Magne Mahre authored
                table
      
      If a temporary table A exists, and a (permanent) table 
      with the same name is attempted created with 
      "CREATE TABLE ... AS SELECT", the create would fail with 
      an error.
         1050: Table 'A' already exists
      
      The error occured in MySQL 5.1 releases, but is not
      present in MySQL 5.5.   This patch adds a regression
      test to ensure that the problem does not reoccur.
      e8b0dc70
    • Alexander Barkov's avatar
      Bug#52849 [Com]: datetime index not work · b41c8186
      Alexander Barkov authored
      Problem: after introduction of "WL#2649 Number-to-string conversions"
      
      This query:
        SET NAMES cp850; -- Or any other non-latin1 ASCII-based character set
        SELECT * FROM t1
        WHERE datetime_column='2010-01-01 00:00:00'
      started to add extra character set conversion: 
        SELECT * FROM t1
        WHERE CONVERT(datetime_column USING cp850)='2010-01-01 00:00:00';
      
      so index on DATETIME column was not used anymore.
      Fix:
        avoid convertion of NUMERIC/DATETIME items
        (i.e. those with derivation DERIVATION_NUMERIC).
      b41c8186
    • Horst.Hunger's avatar
      Patch for 47759 to trunk-bugfixing. · 7f30f576
      Horst.Hunger authored
      7f30f576