An error occurred fetching the project authors.
  1. 08 Mar, 2011 1 commit
    • Jon Olav Hauglid's avatar
      Bug #11755431 (former 47205) · 984988cf
      Jon Olav Hauglid authored
      MAP 'REPAIR TABLE' TO RECREATE +ANALYZE FOR ENGINES NOT
      SUPPORTING NATIVE REPAIR
      
      Executing 'mysqlcheck --check-upgrade --auto-repair ...' will first issue
      'CHECK TABLE FOR UPGRADE' for all tables in the database in order to check if the
      tables are compatible with the current version of MySQL. Any tables that are
      found incompatible are then upgraded using 'REPAIR TABLE'.
      
      The problem was that some engines (e.g. InnoDB) do not support 'REPAIR TABLE'.
      This caused any such tables to be left incompatible. As a result such tables were
      not properly fixed by the mysql_upgrade tool.
      
      This patch fixes the problem by first changing 'CHECK TABLE FOR UPGRADE' to return
      a different error message if the engine does not support REPAIR. Instead of
      "Table upgrade required. Please do "REPAIR TABLE ..." it will report
      "Table rebuild required. Please do "ALTER TABLE ... FORCE ..."
      
      Second, the patch changes mysqlcheck to do 'ALTER TABLE ... FORCE' instead of
      'REPAIR TABLE' in these cases.
      
      This patch also fixes 'ALTER TABLE ... FORCE' to actually rebuild the table.
      This change should be reflected in the documentation. Before this patch,
      'ALTER TABLE ... FORCE' was unused (See Bug#11746162)
      
      Test case added to mysqlcheck.test
      984988cf
  2. 16 Feb, 2011 1 commit
  3. 09 Feb, 2011 1 commit
    • MySQL Build Team's avatar
      Backport into build-201102032246-5.1.52sp1 · 0b054706
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 3520
      > revision-id: sergey.glukhov@oracle.com-20101214093303-wmo9mqcb8rz0wv9f
      > parent: tor.didriksen@oracle.com-20101213161301-81lprlbune7r98dl
      > committer: Sergey Glukhov <sergey.glukhov@oracle.com>
      > branch nick: mysql-5.1-bugteam
      > timestamp: Tue 2010-12-14 12:33:03 +0300
      > message:
      >   Fixed following problems:
      >   --Bug#52157 various crashes and assertions with multi-table update, stored function
      >   --Bug#54475 improper error handling causes cascading crashing failures in innodb/ndb
      >   --Bug#57703 create view cause Assertion failed: 0, file .\item_subselect.cc, line 846
      >   --Bug#57352 valgrind warnings when creating view
      >   --Recently discovered problem when a nested materialized derived table is used
      >     before being populated and it leads to incorrect result
      >   
      >   We have several modes when we should disable subquery evaluation.
      >   The reasons for disabling are different. It could be
      >   uselessness of the evaluation as in case of 'CREATE VIEW'
      >   or 'PREPARE stmt', or we should disable subquery evaluation
      >   if tables are not locked yet as it happens in bug#54475, or
      >   too early evaluation of subqueries can lead to wrong result
      >   as it happened in Bug#19077.
      >   Main problem is that if subquery items are treated as const
      >   they are evaluated in ::fix_fields(), ::fix_length_and_dec()
      >   of the parental items as a lot of these methods have
      >   Item::val_...() calls inside.
      >   We have to make subqueries non-const to prevent unnecessary
      >   subquery evaluation. At the moment we have different methods
      >   for this. Here is a list of these modes:
      >   
      >   1. PREPARE stmt;
      >   We use UNCACHEABLE_PREPARE flag.
      >   It is set during parsing in sql_parse.cc, mysql_new_select() for
      >   each SELECT_LEX object and cleared at the end of PREPARE in
      >   sql_prepare.cc, init_stmt_after_parse(). If this flag is set
      >   subquery becomes non-const and evaluation does not happen.
      >   
      >   2. CREATE|ALTER VIEW, SHOW CREATE VIEW, I_S tables which
      >      process FRM files
      >   We use LEX::view_prepare_mode field. We set it before
      >   view preparation and check this flag in
      >   ::fix_fields(), ::fix_length_and_dec().
      >   Some bugs are fixed using this approach,
      >   some are not(Bug#57352, Bug#57703). The problem here is
      >   that we have a lot of ::fix_fields(), ::fix_length_and_dec()
      >   where we use Item::val_...() calls for const items.
      >   
      >   3. Derived tables with subquery = wrong result(Bug19077)
      >   The reason of this bug is too early subquery evaluation.
      >   It was fixed by adding Item::with_subselect field
      >   The check of this field in appropriate places prevents
      >   const item evaluation if the item have subquery.
      >   The fix for Bug19077 fixes only the problem with
      >   convert_constant_item() function and does not cover
      >   other places(::fix_fields(), ::fix_length_and_dec() again)
      >   where subqueries could be evaluated.
      >   
      >   Example:
      >   CREATE TABLE t1 (i INT, j BIGINT);
      >   INSERT INTO t1 VALUES (1, 2), (2, 2), (3, 2);
      >   SELECT * FROM (SELECT MIN(i) FROM t1
      >   WHERE j = SUBSTRING('12', (SELECT * FROM (SELECT MIN(j) FROM t1) t2))) t3;
      >   DROP TABLE t1;
      >   
      >   4. Derived tables with subquery where subquery
      >      is evaluated before table locking(Bug#54475, Bug#52157)
      >   
      >   Suggested solution is following:
      >   
      >   -Introduce new field LEX::context_analysis_only with the following
      >    possible flags:
      >    #define CONTEXT_ANALYSIS_ONLY_PREPARE 1
      >    #define CONTEXT_ANALYSIS_ONLY_VIEW    2
      >    #define CONTEXT_ANALYSIS_ONLY_DERIVED 4
      >   -Set/clean these flags when we perform
      >    context analysis operation
      >   -Item_subselect::const_item() returns
      >    result depending on LEX::context_analysis_only.
      >    If context_analysis_only is set then we return
      >    FALSE that means that subquery is non-const.
      >    As all subquery types are wrapped by Item_subselect
      >    it allow as to make subquery non-const when
      >    it's necessary.
      0b054706
  4. 26 Jan, 2011 1 commit
  5. 15 Jan, 2011 1 commit
    • 's avatar
      BUG#49124 Security issue with /*!-versioned */ SQL statements on Slave · ade1c74b
      authored
      Backport to 5.0.
      
      /*![:version:] Query Code */, where [:version:] is a sequence of 5 
      digits representing the mysql server version(e.g /*!50200 ... */),
      is a special comment that the query in it can be executed on those 
      servers whose versions are larger than the version appearing in the 
      comment. It leads to a security issue when slave's version is larger 
      than master's. A malicious user can improve his privileges on slaves. 
      Because slave SQL thread is running with SUPER privileges, so it can
      execute queries that he/she does not have privileges on master.
            
      This bug is fixed with the logic below: 
      - To replace '!' with ' ' in the magic comments which are not applied on
        master. So they become common comments and will not be applied on slave.
            
      - Example:
        'INSERT INTO t1 VALUES (1) /*!10000, (2)*/ /*!99999 ,(3)*/
         will be binlogged as
        'INSERT INTO t1 VALUES (1) /*!10000, (2)*/ /* 99999 ,(3)*/
      ade1c74b
  6. 14 Dec, 2010 1 commit
    • Sergey Glukhov's avatar
      Fixed following problems: · cd36a6a5
      Sergey Glukhov authored
      --Bug#52157 various crashes and assertions with multi-table update, stored function
      --Bug#54475 improper error handling causes cascading crashing failures in innodb/ndb
      --Bug#57703 create view cause Assertion failed: 0, file .\item_subselect.cc, line 846
      --Bug#57352 valgrind warnings when creating view
      --Recently discovered problem when a nested materialized derived table is used
        before being populated and it leads to incorrect result
      
      We have several modes when we should disable subquery evaluation.
      The reasons for disabling are different. It could be
      uselessness of the evaluation as in case of 'CREATE VIEW'
      or 'PREPARE stmt', or we should disable subquery evaluation
      if tables are not locked yet as it happens in bug#54475, or
      too early evaluation of subqueries can lead to wrong result
      as it happened in Bug#19077.
      Main problem is that if subquery items are treated as const
      they are evaluated in ::fix_fields(), ::fix_length_and_dec()
      of the parental items as a lot of these methods have
      Item::val_...() calls inside.
      We have to make subqueries non-const to prevent unnecessary
      subquery evaluation. At the moment we have different methods
      for this. Here is a list of these modes:
      
      1. PREPARE stmt;
      We use UNCACHEABLE_PREPARE flag.
      It is set during parsing in sql_parse.cc, mysql_new_select() for
      each SELECT_LEX object and cleared at the end of PREPARE in
      sql_prepare.cc, init_stmt_after_parse(). If this flag is set
      subquery becomes non-const and evaluation does not happen.
      
      2. CREATE|ALTER VIEW, SHOW CREATE VIEW, I_S tables which
         process FRM files
      We use LEX::view_prepare_mode field. We set it before
      view preparation and check this flag in
      ::fix_fields(), ::fix_length_and_dec().
      Some bugs are fixed using this approach,
      some are not(Bug#57352, Bug#57703). The problem here is
      that we have a lot of ::fix_fields(), ::fix_length_and_dec()
      where we use Item::val_...() calls for const items.
      
      3. Derived tables with subquery = wrong result(Bug19077)
      The reason of this bug is too early subquery evaluation.
      It was fixed by adding Item::with_subselect field
      The check of this field in appropriate places prevents
      const item evaluation if the item have subquery.
      The fix for Bug19077 fixes only the problem with
      convert_constant_item() function and does not cover
      other places(::fix_fields(), ::fix_length_and_dec() again)
      where subqueries could be evaluated.
      
      Example:
      CREATE TABLE t1 (i INT, j BIGINT);
      INSERT INTO t1 VALUES (1, 2), (2, 2), (3, 2);
      SELECT * FROM (SELECT MIN(i) FROM t1
      WHERE j = SUBSTRING('12', (SELECT * FROM (SELECT MIN(j) FROM t1) t2))) t3;
      DROP TABLE t1;
      
      4. Derived tables with subquery where subquery
         is evaluated before table locking(Bug#54475, Bug#52157)
      
      Suggested solution is following:
      
      -Introduce new field LEX::context_analysis_only with the following
       possible flags:
       #define CONTEXT_ANALYSIS_ONLY_PREPARE 1
       #define CONTEXT_ANALYSIS_ONLY_VIEW    2
       #define CONTEXT_ANALYSIS_ONLY_DERIVED 4
      -Set/clean these flags when we perform
       context analysis operation
      -Item_subselect::const_item() returns
       result depending on LEX::context_analysis_only.
       If context_analysis_only is set then we return
       FALSE that means that subquery is non-const.
       As all subquery types are wrapped by Item_subselect
       it allow as to make subquery non-const when
       it's necessary.
      cd36a6a5
  7. 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
  8. 25 Oct, 2010 1 commit
  9. 06 Oct, 2010 1 commit
    • Davi Arnaut's avatar
      Bug#49938: Failing assertion: inode or deadlock in fsp/fsp0fsp.c · 5f911fa8
      Davi Arnaut authored
      Bug#54678: InnoDB, TRUNCATE, ALTER, I_S SELECT, crash or deadlock
      
      - Incompatible change: truncate no longer resorts to a row by
      row delete if the storage engine does not support the truncate
      method. Consequently, the count of affected rows does not, in
      any case, reflect the actual number of rows.
      
      - Incompatible change: it is no longer possible to truncate a
      table that participates as a parent in a foreign key constraint,
      unless it is a self-referencing constraint (both parent and child
      are in the same table). To work around this incompatible change
      and still be able to truncate such tables, disable foreign checks
      with SET foreign_key_checks=0 before truncate. Alternatively, if
      foreign key checks are necessary, please use a DELETE statement
      without a WHERE condition.
      
      Problem description:
      
      The problem was that for storage engines that do not support
      truncate table via a external drop and recreate, such as InnoDB
      which implements truncate via a internal drop and recreate, the
      delete_all_rows method could be invoked with a shared metadata
      lock, causing problems if the engine needed exclusive access
      to some internal metadata. This problem originated with the
      fact that there is no truncate specific handler method, which
      ended up leading to a abuse of the delete_all_rows method that
      is primarily used for delete operations without a condition.
      
      Solution:
      
      The solution is to introduce a truncate handler method that is
      invoked when the engine does not support truncation via a table
      drop and recreate. This method is invoked under a exclusive
      metadata lock, so that there is only a single instance of the
      table when the method is invoked.
      
      Also, the method is not invoked and a error is thrown if
      the table is a parent in a non-self-referencing foreign key
      relationship. This was necessary to avoid inconsistency as
      some integrity checks are bypassed. This is inline with the
      fact that truncate is primarily a DDL operation that was
      designed to quickly remove all data from a table.
      5f911fa8
  10. 24 Sep, 2010 1 commit
    • Jon Olav Hauglid's avatar
      Bug #56678 Valgrind warnings from binlog.binlog_unsafe · 71affc14
      Jon Olav Hauglid authored
      After the patch for Bug#54579, multi inserts done with INSERT DELAYED
      are binlogged as normal INSERT. During processing of the statement,
      a new query string without the DELAYED keyword is made. The problem
      was that this new string was incorrectly made when the INSERT DELAYED
      was part of a prepared statement - data was read outside the allocated
      buffer.
      
      The reason for this bug was that a pointer to the position of the
      DELAYED keyword inside the query string was stored when parsing the
      statement. This pointer was then later (at runtime) used (via pointer
      subtraction) to find the number of characters to skip when making a
      new query string without DELAYED. But when the statement was re-executed
      as part of a prepared statement, the original pointer would be invalid
      and the pointer subtraction would give a wrong/random result.
      
      This patch fixes the problem by instead storing the offsets from the
      beginning of the query string to the start and end of the DELAYED 
      keyword. These values will not depend on the memory position
      of the query string at runtime and therefore not give wrong results
      when the statement is executed in a prepared statement.
      
      This bug was a regression introduced by the patch for Bug#54579.
      
      No test case added as this bug is already covered by the existing
      binlog.binlog_unsafe test case when running with valgrind.
      71affc14
  11. 30 Aug, 2010 1 commit
    • 's avatar
      Bug #54579 Wrong unsafe warning for INSERT DELAYED in SBR · 0688c086
      authored
            
      The lock_type is upgrade to TL_WRITE from TL_WRITE_DELAYED for
      INSERT DELAYED when inserting multi values in one statement.
      It's safe. But it causes an unsafe warning in SBR.
            
      Make INSERT DELAYED safe by logging it as INSERT without DELAYED.
      0688c086
  12. 20 Aug, 2010 1 commit
    • Alfranio Correia's avatar
      BUG#53452 Inconsistent behavior of binlog_direct_non_transactional_updates with · c6d4915f
      Alfranio Correia authored
      temp table
                  
      This patch introduces two key changes in the replication's behavior.
                  
      Firstly, it reverts part of BUG#51894 which puts any update to temporary tables
      into the trx-cache. Now, updates to temporary tables are handled according to
      the type of their engines as a regular table.
                  
      Secondly, an unsafe mixed statement, (i.e. a statement that access transactional
      table as well non-transactional or temporary table, and writes to any of them),
      are written into the trx-cache in order to minimize errors in the execution when
      the statement logging format is in use.
                  
      Such changes has a direct impact on which statements are classified as unsafe
      statements and thus part of BUG#53259 is reverted.
      c6d4915f
  13. 18 Aug, 2010 1 commit
    • 's avatar
      WL#5370 Keep forward-compatibility when changing · b766a51f
      authored
              'CREATE TABLE IF NOT EXISTS ... SELECT' behaviour
      BUG#55474, BUG#55499, BUG#55598, BUG#55616 and BUG#55777 are fixed
      in this patch too.
      
      This is the 5.1 part.
      It implements:
      - if the table exists, binlog two events: CREATE TABLE IF NOT EXISTS
        and INSERT ... SELECT
      
      - Insert nothing and binlog nothing on master if the existing object
        is a view. It only generates a warning that table already exists.
      b766a51f
  14. 16 Aug, 2010 2 commits
  15. 10 Aug, 2010 1 commit
    • Alfranio Correia's avatar
      BUG#50312 Warnings for unsafe sub-statement not returned to client · bd3aa7eb
      Alfranio Correia authored
                              
      After BUG#36649, warnings for sub-statements are cleared when a 
      new sub-statement is started. This is problematic since it suppresses
      warnings for unsafe statements in some cases. It is important that we
      always give a warning to the client, because the user needs to know
      when there is a risk that the slave goes out of sync.
                              
      We fixed the problem by generating warning messages for unsafe statements
      while returning from a stored procedure, function, trigger or while
      executing a top level statement.
                              
      We also started checking unsafeness when both performance and log tables are
      used. This is necessary after the performance schema which does a distinction
      between performance and log tables.
      bd3aa7eb
  16. 09 Aug, 2010 1 commit
  17. 29 Jul, 2010 1 commit
    • 's avatar
      BUG#49124 Security issue with /*!-versioned */ SQL statements on Slave · 2ad690fd
      authored
      /*![:version:] Query Code */, where [:version:] is a sequence of 5 
      digits representing the mysql server version(e.g /*!50200 ... */),
      is a special comment that the query in it can be executed on those 
      servers whose versions are larger than the version appearing in the 
      comment. It leads to a security issue when slave's version is larger 
      than master's. A malicious user can improve his privileges on slaves. 
      Because slave SQL thread is running with SUPER privileges, so it can
      execute queries that he/she does not have privileges on master.
      
      This bug is fixed with the logic below: 
      - To replace '!' with ' ' in the magic comments which are not applied on
        master. So they become common comments and will not be applied on slave.
      
      - Example:
        'INSERT INTO t1 VALUES (1) /*!10000, (2)*/ /*!99999 ,(3)*/
        will be binlogged as
        'INSERT INTO t1 VALUES (1) /*!10000, (2)*/ /* 99999 ,(3)*/
      2ad690fd
  18. 23 Jul, 2010 2 commits
  19. 22 Jun, 2010 1 commit
  20. 10 Jun, 2010 1 commit
    • Davi Arnaut's avatar
      Bug#42733: Type-punning warnings when compiling MySQL -- · 53b88296
      Davi Arnaut authored
                  strict aliasing violations.
      
      One somewhat major source of strict-aliasing violations and
      related warnings is the SQL_LIST structure. For example,
      consider its member function `link_in_list` which takes
      a pointer to pointer of type T (any type) as a pointer to
      pointer to unsigned char. Dereferencing this pointer, which
      is done to reset the next field, violates strict-aliasing
      rules and might cause problems for surrounding code that
      uses the next field of the object being added to the list.
      
      The solution is to use templates to parametrize the SQL_LIST
      structure in order to deference the pointers with compatible
      types. As a side bonus, it becomes possible to remove quite
      a few casts related to acessing data members of SQL_LIST.
      53b88296
  21. 25 May, 2010 1 commit
    • 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
  22. 21 May, 2010 1 commit
    • Alexey Kopytov's avatar
      Bug #42064: low memory crash when importing hex strings, in · 779e2a96
      Alexey Kopytov authored
                  Item_hex_string::Item_hex_string
      
      The status of memory allocation in the Lex_input_stream (called
      from the Parser_state constructor) was not checked which led to
      a parser crash in case of the out-of-memory error.
      
      The solution is to introduce new init() member function in
      Parser_state and Lex_input_stream so that status of memory
      allocation can be returned to the caller.
      779e2a96
  23. 14 May, 2010 1 commit
    • 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
  24. 07 May, 2010 1 commit
    • Konstantin Osipov's avatar
      Draft patch that fixes and a sketches test cases for: · 5ac769be
      Konstantin Osipov authored
      Bug#20837 Apparent change of isolation level during transaction,
      Bug#46527 COMMIT AND CHAIN RELEASE does not make sense,
      Bug#53343 completion_type=1, COMMIT/ROLLBACK AND CHAIN don't 
      preserve the isolation level
      Bug#53346 completion_type has strange effect in a stored 
      procedure/prepared statement
      
      Make thd->tx_isolation mean strictly "current transaction 
      isolation level"
      Make thd->variables.tx_isolation mean "current session isolation
      level".
      The current transaction isolation level is now established
      at transaction start. If there was a SET TRANSACTION
      ISOLATION LEVEL statement, the value is taken from it.
      Otherwise, the session value is used.
      A change in a session value, made while a transaction is active,
      whereas still allowed, no longer has any effect on the
      current transaction isolation level. This is an incompatible
      change.
      A change in a session isolation level, made while there is
      no active transaction, overrides SET TRANSACTION statement,
      if there was any.
      Changed the impelmentation to not look at @@session.completion_type
      in the parser, and thus fixed Bug#53346.
      Changed the parser to not allow AND NO CHAIN RELEASE,
      and thus fixed Bug#46527.
      Changed the transaction API to take the current transaction
      isolation level into account:
      - BEGIN/COMMIT now do preserve the current transaction
      isolation level if chaining is on.
      - implicit commit, XA COMMIT or XA ROLLBACK or autocommit don't.
      5ac769be
  25. 28 Apr, 2010 1 commit
    • Konstantin Osipov's avatar
      Committing on behalf or Dmitry Lenev: · 8280fdd3
      Konstantin Osipov authored
      Fix for bug #46947 "Embedded SELECT without FOR UPDATE is
      causing a lock", with after-review fixes.
      
      SELECT statements with subqueries referencing InnoDB tables
      were acquiring shared locks on rows in these tables when they
      were executed in REPEATABLE-READ mode and with statement or
      mixed mode binary logging turned on.
      
      This was a regression which were introduced when fixing
      bug 39843.
      
      The problem was that for tables belonging to subqueries
      parser set TL_READ_DEFAULT as a lock type. In cases when
      statement/mixed binary logging at open_tables() time this
      type of lock was converted to TL_READ_NO_INSERT lock at
      open_tables() time and caused InnoDB engine to acquire
      shared locks on reads from these tables. Although in some
      cases such behavior was correct (e.g. for subqueries in
      DELETE) in case of SELECT it has caused unnecessary locking.
      
      This patch tries to solve this problem by rethinking our
      approach to how we handle locking for SELECT and subqueries.
      Now we always set TL_READ_DEFAULT lock type for all cases
      when we read data. When at open_tables() time this lock
      is interpreted as TL_READ_NO_INSERT or TL_READ depending
      on whether this statement as a whole or call to function
      which uses particular table should be written to the
      binary log or not (if yes then statement should be properly
      serialized with concurrent statements and stronger lock
      should be acquired).
      
      Test coverage is added for both InnoDB and MyISAM.
      
      This patch introduces an "incompatible" change in locking
      scheme for subqueries used in SELECT ... FOR UPDATE and
      SELECT .. IN SHARE MODE.
      In 4.1 the server would use a snapshot InnoDB read for 
      subqueries in SELECT FOR UPDATE and SELECT .. IN SHARE MODE
      statements, regardless of whether the binary log is on or off.
      If the user required a different type of read (i.e. locking read),
      he/she could request so explicitly by providing FOR UPDATE/IN SHARE MODE
      clause for each individual subquery.
      On of the patches for 5.0 broke this behaviour (which was not documented
      or tested), and started to use locking reads fora all subqueries in SELECT ... 
      FOR UPDATE/IN SHARE MODE. This patch restored 4.1 behaviour.
      8280fdd3
  26. 31 Mar, 2010 2 commits
    • Mats Kindahl's avatar
      WL#5030: Split and remove mysql_priv.h · e409d6f6
      Mats Kindahl authored
      This patch:
      
      - Moves all definitions from the mysql_priv.h file into
        header files for the component where the variable is
        defined
      - Creates header files if the component lacks one
      - Eliminates all include directives from mysql_priv.h
      - Eliminates all circular include cycles
      - Rename time.cc to sql_time.cc
      - Rename mysql_priv.h to sql_priv.h
      e409d6f6
    • Alfranio Correia's avatar
      BUG#51291 Unfortunate effect around variable binlog_direct_non_transactional_updates · 7827688f
      Alfranio Correia authored
      BUG#46364 introduced the flag binlog_direct_non_transactional_updates which
      would make N-changes to be written to the binary log upon committing the
      statement when "ON". On the other hand, when "OFF" the option was supposed
      to mimic the behavior in 5.1. However, the implementation was not mimicking
      the behavior correctly and the following bugs popped up:
      
        Case #1: N-changes executed within a transaction would go into
                 the S-cache. When later in the same transaction a
                 T-change occurs, N-changes following it were written
                 to the T-cache instead of the S-cache. In some cases,
                 this raises problems. For example, a
                 Table_map_log_event being written initially into the
                 S-cache, together with the initial N-changes, would be
                 absent from the T-cache. This would log N-changes
                 orphaned from a Table_map_log_event (thence discarded
                 at the slave). (MIXED and ROW)
      
         Case #2: When rolling back a transaction, the N-changes that
                  might be in the T-cache were disregarded and
                  truncated along with the T-changes. (MIXED and ROW)
      
         Case #3: When a MIXED statement (TN) is ahead of any other
                  T-changes in the transaction and it fails, it is kept
                  in the T-cache until the transaction ends. This is
                  not the case in 5.1 or Betony (5.5.2). In these, the
                  failed TN statement would be written to the binlog at
                  the same instant it had failed and not deferred until
                  transaction end. (SBR)
      
      To fix these problems, we have decided to do what follows:
      
         For Case #1 and #2, we circumvent them:
      
            1. by not letting binlog_direct_non_transactional_updates
               affect MIXED and RBR. These modes will keep the behavior
               provided by WL#2687. Although this will make Celosia to
               behave differently from 5.1, an execution will be always
               safe under such modes in the sense that slaves will never
               go out sync. In 5.1, using either MIXED or ROW while
               mixing N-statements and T-statements was not safe.
      
         For Case #3, we don't actually fix it. We:
      
            1. keep it and make all MIXED statements whether they end
               up failing or not or whether they are up front in the
               transaction or after some transactional change to always
               be stored in the T-cache. This means that it is written
               to the binary log on transaction commit/rollback only.
      
            2. We make the warning message even more specific about the
               MIXED statement and SBR.
      7827688f
  27. 28 Mar, 2010 1 commit
    • 's avatar
      Bug #50095 Multi statement including CREATE EVENT causes rotten binlog entry · 8d22c5f3
      authored
      The log event of 'CREATE EVENT' was being binlogged with garbage
      at the end of the query if 'CREATE EVENT' is followed by another SQL statement
      and they were executed as one command.
      for example:
          DELIMITER |;
          CREATE EVENT e1 ON EVERY DAY DO SELECT 1; SELECT 'a';
          DELIMITER ;|
      When binlogging 'CREATE EVENT', we always create a new statement with definer
      and write it into the log event. The new statement is made from cpp_buf(preprocessed buffer).
      which is not a c string(end with '\0'), but it is copied as a c string.
      
      In this patch, cpp_buf is copied with its length.
      8d22c5f3
  28. 22 Feb, 2010 1 commit
    • Alfranio Correia's avatar
      BUG#49019 Mixing self-logging eng. and regular eng. does not switch to row in mixed mode · 7194aec8
      Alfranio Correia authored
      Reading from a self-logging engine and updating a transactional engine such as Innodb
      generates changes that are written to the binary log in the statement format and may
      make slaves diverge. In the mixed mode, such changes should be written to the binary
      log in the row format.
      
      Note that the issue does not happen if we mix a self-logging engine and MyIsam
      as this case is caught by checking the mixture of non-transactional and transactional
      engines.
      
      So, we classify a mixed statement where one reads from NDB and writes into another 
      engine as unsafe:
      
      if (multi_engine && flags_some_set & HA_HAS_OWN_BINLOGGING)
        lex->set_stmt_unsafe(LEX::BINLOG_STMT_UNSAFE_MULTIPLE_ENGINES_AND_SELF_LOGGING_ENGINE);
      7194aec8
  29. 06 Feb, 2010 1 commit
    • Gleb Shchepa's avatar
      Bug #45640: optimizer bug produces wrong results · 57e5f848
      Gleb Shchepa authored
      Grouping by a subquery in a query with a distinct aggregate
      function lead to a wrong result (wrong and unordered
      grouping values).
      
      There are two related problems:
      
      1) The query like this:
      
         SELECT (SELECT t1.a) aa, COUNT(DISTINCT b) c
         FROM t1 GROUP BY aa
      
      returned wrong result, because the outer reference "t1.a"
      in the subquery was substituted with the Item_ref item.
      
      The Item_ref item obtains data from the result_field object
      that refreshes once after the end of each group. This data
      is not applicable to filesort since filesort() doesn't care
      about groups (and doesn't update result_field objects with
      copy_fields() and so on). Also that data is not applicable
      to group separation algorithm: end_send_group() checks every
      record with test_if_group_changed() that evaluates Item_ref
      items, but it refreshes those Item_ref-s only after the end
      of group, that is a vicious circle and the grouped column
      values in the output are shifted.
      
      Fix: if
             a) we grouping by a subquery and
             b) that subquery has outer references to FROM list
                of the grouping query,
           then we substitute these outer references with
           Item_direct_ref like references under aggregate
           functions: Item_direct_ref obtains data directly
           from the current record.
      
      2) The query with a non-trivial grouping expression like:
      
         SELECT (SELECT t1.a) aa, COUNT(DISTINCT b) c
         FROM t1 GROUP BY aa+0
      
      also returned wrong result, since JOIN::exec() substitutes
      references to top-level aliases in SELECT list with Item_copy
      caching items. Item_copy items have same refreshing policy
      as Item_ref items, so the whole groping expression with
      Item_copy inside returns wrong result in filesort() and
      end_send_group().
      
      Fix: include aliased items into GROUP BY item tree instead
           of Item_ref references to them.
      57e5f848
  30. 02 Feb, 2010 1 commit
    • Alexander Nozdrin's avatar
      Revert a patch for Bug#48231, which introduced valgrind warnings. · f392edda
      Alexander Nozdrin authored
      Original revision:
      ------------------------------------------------------------
      revision-id: li-bing.song@sun.com-20100130124925-o6sfex42b6noyc6x
      parent: joro@sun.com-20100129145427-0n79l9hnk0q43ajk
      committer: <Li-Bing.Song@sun.com>
      branch nick: mysql-5.1-bugteam
      timestamp: Sat 2010-01-30 20:49:25 +0800
      message:
        Bug #48321  CURRENT_USER() incorrectly replicated for DROP/RENAME USER;
                    REVOKE/GRANT; ALTER EVENT.
        
        The following statements support the CURRENT_USER() where a user is needed.
          DROP USER 
          RENAME USER CURRENT_USER() ...
          GRANT ... TO CURRENT_USER()
          REVOKE ... FROM CURRENT_USER()
          ALTER DEFINER = CURRENT_USER() EVENT
        but, When these statements are binlogged, CURRENT_USER() just is binlogged
        as 'CURRENT_USER()', it is not expanded to the real user name. When slave 
        executes the log event, 'CURRENT_USER()' is expand to the user of slave 
        SQL thread, but SQL thread's user name always NULL. This breaks the replication.
        
        After this patch, All above statements are rewritten when they are binlogged.
        The CURRENT_USER() is expanded to the real user's name and host.
      ------------------------------------------------------------
      f392edda
  31. 30 Jan, 2010 1 commit
    • 's avatar
      Bug #48321 CURRENT_USER() incorrectly replicated for DROP/RENAME USER; · 788c28ac
      authored
                  REVOKE/GRANT; ALTER EVENT.
      
      The following statements support the CURRENT_USER() where a user is needed.
        DROP USER 
        RENAME USER CURRENT_USER() ...
        GRANT ... TO CURRENT_USER()
        REVOKE ... FROM CURRENT_USER()
        ALTER DEFINER = CURRENT_USER() EVENT
      but, When these statements are binlogged, CURRENT_USER() just is binlogged
      as 'CURRENT_USER()', it is not expanded to the real user name. When slave 
      executes the log event, 'CURRENT_USER()' is expand to the user of slave 
      SQL thread, but SQL thread's user name always NULL. This breaks the replication.
      
      After this patch, All above statements are rewritten when they are binlogged.
      The CURRENT_USER() is expanded to the real user's name and host.
      788c28ac
  32. 29 Jan, 2010 1 commit
    • Andrei Elkin's avatar
      Bug #50192 Strange effect in replication test, trigger, auto_increment · 7db8e764
      Andrei Elkin authored
      The auto-inc unsafe warning makes sense even though it's just
      one auto-inc table could be involved via a trigger or a stored
      function.
      However its content was not updated by bug@45677 fixes continuing to mention
      two tables whereas the fixes refined semantics of replication of auto_increment 
      in stored routine.
      
      Fixed with updating the error message, renaming the error and an internal unsafe-condition 
      constants.
      
      A documentation notice
      ======================
      
            Inserting into an autoincrement column in a stored function or a trigger
            is unsafe for replication.
            Even with just one autoincrement column, if the routine is invoked more than 
            once slave is not guaranteed to execute the statement graph same way as 
            the master.
            And since it's impossible to estimate how many times a routine can be invoked at 
            the query pre-execution phase (see lock_tables), the statement is marked
            pessimistically unsafe. 
      7db8e764
  33. 25 Jan, 2010 1 commit
  34. 22 Dec, 2009 1 commit
    • Sergei Golubchik's avatar
      WL#4738 streamline/simplify @@variable creation process · ae2768ce
      Sergei Golubchik authored
      Bug#16565 mysqld --help --verbose does not order variablesBug#20413 sql_slave_skip_counter is not shown in show variables
      Bug#20415 Output of mysqld --help --verbose is incomplete
      Bug#25430 variable not found in SELECT @@global.ft_max_word_len;
      Bug#32902 plugin variables don't know their names
      Bug#34599 MySQLD Option and Variable Reference need to be consistent in formatting!
      Bug#34829 No default value for variable and setting default does not raise error
      Bug#34834 ? Is accepted as a valid sql mode
      Bug#34878 Few variables have default value according to documentation but error occurs  
      Bug#34883 ft_boolean_syntax cant be assigned from user variable to global var.
      Bug#37187 `INFORMATION_SCHEMA`.`GLOBAL_VARIABLES`: inconsistent status
      Bug#40988 log_output_basic.test succeeded though syntactically false.
      Bug#41010 enum-style command-line options are not honoured (maria.maria-recover fails)
      Bug#42103 Setting key_buffer_size to a negative value may lead to very large allocations 
      Bug#44691 Some plugins configured as MYSQL_PLUGIN_MANDATORY in can be disabled
      Bug#44797 plugins w/o command-line options have no disabling option in --help
      Bug#46314 string system variables don't support expressions
      Bug#46470 sys_vars.max_binlog_cache_size_basic_32 is broken
      Bug#46586 When using the plugin interface the type "set" for options caused a crash.
      Bug#47212 Crash in DBUG_PRINT in mysqltest.cc when trying to print octal number
      Bug#48758 mysqltest crashes on sys_vars.collation_server_basic in gcov builds
      Bug#49417 some complaints about mysqld --help --verbose output
      Bug#49540 DEFAULT value of binlog_format isn't the default value
      Bug#49640 ambiguous option '--skip-skip-myisam' (double skip prefix)
      Bug#49644 init_connect and \0
      Bug#49645 init_slave and multi-byte characters
      Bug#49646 mysql --show-warnings crashes when server dies
      ae2768ce
  35. 08 Dec, 2009 1 commit
    • Konstantin Osipov's avatar
      Backport of: · c20afa6d
      Konstantin Osipov authored
      ----------------------------------------------------------
      revno: 2617.69.24
      committer: Konstantin Osipov <kostja@sun.com>
      branch nick: 5.4-42546
      timestamp: Fri 2009-08-14 19:22:05 +0400
      message:
        A pre-requisite for a fix for Bug#42546 "Backup: RESTORE fails, thinking it
        finds an existing table"
        Back-port from WL 148 "Foreign keys" feature tree a patch
        that introduced Prelocking_strategy class -- a way to parameterize
        open_tables() behaviour, implemented by Dmitry Lenev.
      
      (Part of WL#4284).
      c20afa6d
  36. 27 Nov, 2009 1 commit
  37. 30 Nov, 2009 1 commit
    • Tor Didriksen's avatar
      backport of: · 76223362
      Tor Didriksen authored
              ------------------------------------------------------------
              revno: 2617.81.1
              revision-id: tor.didriksen@sun.com-20090924061133-qo02zotz3yypmfpk
              parent: davi.arnaut@sun.com-20090923203724-tvz7x8dauzp686v7
              committer: Tor Didriksen <tor.didriksen@sun.com>
              branch nick: 6.0-codebase-bf-opt
              timestamp: Thu 2009-09-24 08:11:33 +0200
              message:
                Bug#47511 Segmentation fault during cleanup in sql_union (events_bugs.test)
                
      76223362