An error occurred fetching the project authors.
  1. 03 Nov, 2009 1 commit
    • Alfranio Correia's avatar
      WL#2687 WL#5072 BUG#40278 BUG#47175 · 60d46624
      Alfranio Correia authored
      Non-transactional updates that take place inside a transaction present problems
      for logging because they are visible to other clients before the transaction
      is committed, and they are not rolled back even if the transaction is rolled
      back. It is not always possible to log correctly in statement format when both
      transactional and non-transactional tables are used in the same transaction.
      
      In the current patch, we ensure that such scenario is completely safe under the
      ROW and MIXED modes.
      60d46624
  2. 23 Oct, 2009 1 commit
    • Jon Olav Hauglid's avatar
      Bug #47919 assert in open_table during ALTER temporary table · 111da3a4
      Jon Olav Hauglid authored
      This assertion would occur if UPDATE was used to update multiple
      tables containing an AUTO_INCREMENT column and if the inserted
      row had a user-supplied value for that column. The assertion 
      could then be triggered by the next statement.
      
      The problem was only noticeable on debug builds of the server.
      
      The cause of the problem was that the code for multi update did
      not properly reset the TABLE->auto_increment_if_null flag after update.
      The flag is used to indicate that a non-null value of an auto_increment field
      has been provided by the user or retrieved from a current record.
      Open_tables() contains an assertion that tests this flag, and this
      was triggered in this case by ALTER TABLE.
      
      This patch fixes the problem by resetting the auto_increment_if_null
      field to FALSE once a row has been updated.
      
      This bug is similar to Bug#47274, but for multi update rather
      than INSERT DELAYED.
      
      Test case added to update.test.
      111da3a4
  3. 16 Oct, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #40877: multi statement execution fails in 5.1.30 · 8f6f3dba
      Georgi Kodinov authored
            
      Implemented the server infrastructure for the fix:
      
      1. Added a function LEX_STRING *thd_query_string(THD) to return
      a LEX_STRING structure instead of char *.
      This is the function that must be called in innodb instead of 
      thd_query()
      
      2. Did some encapsulation in THD : aggregated thd_query and 
      thd_query_length into a LEX_STRING and made accessor and mutator 
      methods for easy code updating. 
      
      3. Updated the server code to use the new methods where applicable.
      8f6f3dba
  4. 28 Aug, 2009 1 commit
    • Staale Smedseng's avatar
      Bug #43414 Parenthesis (and other) warnings compiling MySQL · 2217de25
      Staale Smedseng authored
      with gcc 4.3.2
            
      This patch fixes a number of GCC warnings about variables used
      before initialized. A new macro UNINIT_VAR() is introduced for
      use in the variable declaration, and LINT_INIT() usage will be
      gradually deprecated. (A workaround is used for g++, pending a
      patch for a g++ bug.)
            
      GCC warnings for unused results (attribute warn_unused_result)
      for a number of system calls (present at least in later
      Ubuntus, where the usual void cast trick doesn't work) are
      also fixed.
      2217de25
  5. 20 Aug, 2009 1 commit
  6. 14 Jul, 2009 1 commit
    • Sven Sandberg's avatar
      BUG#39934: Slave stops for engine that only support row-based logging · f3985c64
      Sven Sandberg authored
      General overview:
      The logic for switching to row format when binlog_format=MIXED had
      numerous flaws. The underlying problem was the lack of a consistent
      architecture.
      General purpose of this changeset:
      This changeset introduces an architecture for switching to row format
      when binlog_format=MIXED. It enforces the architecture where it has
      to. It leaves some bugs to be fixed later. It adds extensive tests to
      verify that unsafe statements work as expected and that appropriate
      errors are produced by problems with the selection of binlog format.
      It was not practical to split this into smaller pieces of work.
      
      Problem 1:
      To determine the logging mode, the code has to take several parameters
      into account (namely: (1) the value of binlog_format; (2) the
      capabilities of the engines; (3) the type of the current statement:
      normal, unsafe, or row injection). These parameters may conflict in
      several ways, namely:
       - binlog_format=STATEMENT for a row injection
       - binlog_format=STATEMENT for an unsafe statement
       - binlog_format=STATEMENT for an engine only supporting row logging
       - binlog_format=ROW for an engine only supporting statement logging
       - statement is unsafe and engine does not support row logging
       - row injection in a table that does not support statement logging
       - statement modifies one table that does not support row logging and
         one that does not support statement logging
      Several of these conflicts were not detected, or were detected with
      an inappropriate error message. The problem of BUG#39934 was that no
      appropriate error message was written for the case when an engine
      only supporting row logging executed a row injection with
      binlog_format=ROW. However, all above cases must be handled.
      Fix 1:
      Introduce new error codes (sql/share/errmsg.txt). Ensure that all
      conditions are detected and handled in decide_logging_format()
      
      Problem 2:
      The binlog format shall be determined once per statement, in
      decide_logging_format(). It shall not be changed before or after that.
      Before decide_logging_format() is called, all information necessary to
      determine the logging format must be available. This principle ensures
      that all unsafe statements are handled in a consistent way.
      However, this principle is not followed:
      thd->set_current_stmt_binlog_row_based_if_mixed() is called in several
      places, including from code executing UPDATE..LIMIT,
      INSERT..SELECT..LIMIT, DELETE..LIMIT, INSERT DELAYED, and
      SET @@binlog_format. After Problem 1 was fixed, that caused
      inconsistencies where these unsafe statements would not print the
      appropriate warnings or errors for some of the conflicts.
      Fix 2:
      Remove calls to THD::set_current_stmt_binlog_row_based_if_mixed() from
      code executed after decide_logging_format(). Compensate by calling the
      set_current_stmt_unsafe() at parse time. This way, all unsafe statements
      are detected by decide_logging_format().
      
      Problem 3:
      INSERT DELAYED is not unsafe: it is logged in statement format even if
      binlog_format=MIXED, and no warning is printed even if
      binlog_format=STATEMENT. This is BUG#45825.
      Fix 3:
      Made INSERT DELAYED set itself to unsafe at parse time. This allows
      decide_logging_format() to detect that a warning should be printed or
      the binlog_format changed.
      
      Problem 4:
      LIMIT clause were not marked as unsafe when executed inside stored
      functions/triggers/views/prepared statements. This is
      BUG#45785.
      Fix 4:
      Make statements containing the LIMIT clause marked as unsafe at
      parse time, instead of at execution time. This allows propagating
      unsafe-ness to the view.
      f3985c64
  7. 13 Jul, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #40113: Embedded SELECT inside UPDATE or DELETE can timeout · 80dd3a59
      Georgi Kodinov authored
      without error
      
      When using quick access methods for searching rows in UPDATE or 
      DELETE there was no check if a fatal error was not already sent 
      to the client while evaluating the quick condition.
      As a result a false OK (following the error) was sent to the 
      client and the error was thus transformed into a warning.
      
      Fixed by checking for errors sent to the client during 
      SQL_SELECT::check_quick() and treating them as real errors.
      
      Fixed a wrong test case in group_min_max.test
      Fixed a wrong return code in mysql_update() and mysql_delete()
      80dd3a59
  8. 18 Jun, 2009 1 commit
    • Alfranio Correia's avatar
      BUG#43929 binlog corruption when max_binlog_cache_size is exceeded · ac1b464a
      Alfranio Correia authored
      Large transactions and statements may corrupt the binary log if the size of the
      cache, which is set by the max_binlog_cache_size, is not enough to store the
      the changes.
      
      In a nutshell, to fix the bug, we save the position of the next character in the
      cache before starting processing a statement. If there is a problem, we simply
      restore the position thus removing any effect of the statement from the cache.
      Unfortunately, to avoid corrupting the binary log, we may end up loosing changes
      on non-transactional tables if they do not fit in the cache. In such cases, we
      store an Incident_log_event in order to stop the slave and alert users that some
      changes were not logged.
      
      Precisely, for every non-transactional changes that do not fit into the cache,
      we do the following:
        a) the statement is *not* logged
        b) an incident event is logged after committing/rolling back the transaction,
        if any. Note that if a failure happens before writing the incident event to
        the binary log, the slave will not stop and the master will not have reported
        any error.
        c) its respective statement gives an error
      
      For transactional changes that do not fit into the cache, we do the following:
        a) the statement is *not* logged
        b) its respective statement gives an error
      
      To work properly, this patch requires two additional things. Firstly, callers to
      MYSQL_BIN_LOG::write and THD::binlog_query must handle any error returned and
      take the appropriate actions such as undoing the effects of a statement. We
      already changed some calls in the sql_insert.cc, sql_update.cc and sql_insert.cc
      modules but the remaining calls spread all over the code should be handled in
      BUG#37148. Secondly, statements must be either classified as DDL or DML because
      DDLs that do not get into the cache must generate an incident event since they
      cannot be rolled back.
      ac1b464a
  9. 17 Jun, 2009 1 commit
    • Staale Smedseng's avatar
      Bug #43414 Parenthesis (and other) warnings compiling MySQL · 30fccdaa
      Staale Smedseng authored
      with gcc 4.3.2
            
      Compiling MySQL with gcc 4.3.2 and later produces a number of 
      warnings, many of which are new with the recent compiler
      versions.
                        
      This bug will be resolved in more than one patch to limit the
      size of changesets. This is the second patch, fixing more
      of the warnings.
      30fccdaa
  10. 10 Jun, 2009 1 commit
    • Staale Smedseng's avatar
      Bug #43414 Parenthesis (and other) warnings compiling MySQL · e6e1f4ac
      Staale Smedseng authored
      with gcc 4.3.2
      
      Compiling MySQL with gcc 4.3.2 and later produces a number of 
      warnings, many of which are new with the recent compiler
      versions.
                  
      This bug will be resolved in more than one patch to limit the
      size of changesets. This is the second patch, fixing more
      of the warnings.
      e6e1f4ac
  11. 30 May, 2009 1 commit
  12. 05 May, 2009 1 commit
    • Martin Hansson's avatar
      Bug#43580: Issue with Innodb on multi-table update · 2afccc1b
      Martin Hansson authored
                              
      Certain multi-updates gave different results on InnoDB from
      to MyISAM, due to on-the-fly updates being used on the former and
      the update order matters.
      Fixed by turning off on-the-fly updates when update order 
      dependencies are present.
      2afccc1b
  13. 04 May, 2009 1 commit
  14. 27 Mar, 2009 1 commit
    • He Zhenxing's avatar
      BUG#37145 Killing a statement doing DDL may log binlog event with error code 1053 · 95301268
      He Zhenxing authored
      When the thread executing a DDL was killed after finished its
      execution but before writing the binlog event, the error code in
      the binlog event could be set wrongly to ER_SERVER_SHUTDOWN or
      ER_QUERY_INTERRUPTED.
      
      This patch fixed the problem by ignoring the kill status when
      constructing the event for DDL statements.
      
      This patch also included the following changes in order to
      provide the test case.
      
       1) modified mysqltest to support variable for connection command
      
       2) modified mysql-test-run.pl, add new variable MYSQL_SLAVE to
          run mysql client against the slave mysqld.
      95301268
  15. 05 Mar, 2009 1 commit
  16. 05 Feb, 2009 1 commit
  17. 28 Nov, 2008 1 commit
    • Gleb Shchepa's avatar
      Bug #40745: Error during WHERE clause calculation in UPDATE · c762d934
      Gleb Shchepa authored
                  leads to an assertion failure
      
      Any run-time error in stored function (like recursive function
      call or update of table that is already updating by statement
      which invoked this stored function etc.) that was used in some
      expression of the single-table UPDATE statement caused an
      assertion failure.
      Multiple-table UPDATE (as well as INSERT and both single- and
      multiple-table DELETE) are not affected.
      c762d934
  18. 27 Nov, 2008 1 commit
  19. 10 Nov, 2008 1 commit
  20. 09 Oct, 2008 1 commit
    • Gleb Shchepa's avatar
      Bug#38499: flush tables and multitable table update with · 0b38c93d
      Gleb Shchepa authored
                 derived table cause crash
      
      When a multi-UPDATE command fails to lock some table, and
      subsequently succeeds, the tables need to be reopened if
      they were altered. But the reopening procedure failed for
      derived tables.
      
      Extra cleanup has been added.
      0b38c93d
  21. 07 Oct, 2008 1 commit
    • Gleb Shchepa's avatar
      Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while · e219979e
      Gleb Shchepa authored
                ``FLUSH TABLES WITH READ LOCK''
      
      Concurrent execution of 1) multitable update with a
      NATURAL/USING join and 2) a such query as "FLUSH TABLES
      WITH READ LOCK" or "ALTER TABLE" of updating table led
      to a server crash.
      
      
      The mysql_multi_update_prepare() function call is optimized
      to lock updating tables only, so it postpones locking to
      the last, and if locking fails, it does cleanup of modified
      syntax structures and repeats a query analysis.  However,
      that cleanup procedure was incomplete for NATURAL/USING join
      syntax data: 1) some Field_item items pointed into freed
      table structures, and 2) the TABLE_LIST::join_columns fields
      was not reset.
      
      Major change:
        short-living Field *Natural_join_column::table_field has
        been replaced with long-living Item*.
      e219979e
  22. 29 Sep, 2008 1 commit
    • Davi Arnaut's avatar
      Bug#34306: Can't make copy of log tables when server binary log is enabled · 35ffaf10
      Davi Arnaut authored
      The problem is that when statement-based replication was enabled,
      statements such as INSERT INTO .. SELECT FROM .. and CREATE TABLE
      .. SELECT FROM need to grab a read lock on the source table that
      does not permit concurrent inserts, which would in turn be denied
      if the source table is a log table because log tables can't be
      locked exclusively.
      
      The solution is to not take such a lock when the source table is
      a log table as it is unsafe to replicate log tables under statement
      based replication. Furthermore, the read lock that does not permits
      concurrent inserts is now only taken if statement-based replication
      is enabled and if the source table is not a log table.
      35ffaf10
  23. 26 Aug, 2008 1 commit
  24. 31 Jul, 2008 1 commit
    • He Zhenxing's avatar
      BUG#37051 Replication rules not evaluated correctly · e6ac8830
      He Zhenxing authored
      The problem of this bug is that we need to get the list of tables
      to be updated for a multi-table update statement, which requires to
      open all the tables referenced by the statement and resolve all
      the fields involved in update in order to figure out the list of
      tables for update. However if there are replicate filter rules,
      some tables might not exist on slave and result in a failure
      before we could examine the filter rules.
      
      I think the whole problem can not be solved on slave alone,
      the master must record and send the information of tables
      involved for update to slave, so that the slave do not need to
      open all the tables referenced by the multi-table update statement to
      figure out which tables are involved for update.
      
      So a status variable is added to Query_log event to store the
      value of table map for update on master. And on slave, it will
      try to get the value of this variable and use it to examine
      filter rules without opening any tables on slave, if this values
      is not available, the old approach is used and thus the bug will
      still occur for when replicating from old masters.
      e6ac8830
  25. 15 Jul, 2008 1 commit
    • Sergey Petrunia's avatar
      BUG#35478: sort_union() returns bad data when sort_buffer_size is hit · 2951f00b
      Sergey Petrunia authored
      - In QUICK_INDEX_MERGE_SELECT::read_keys_and_merge: when we got table->sort from Unique,
        tell init_read_record() not to use rr_from_cache() because a) rowids are already sorted
        and b) it might be that the the data is used by filesort(), which will need record rowids
        (which rr_from_cache() cannot provide).
      - Fully de-initialize the table->sort read in QUICK_INDEX_MERGE_SELECT::get_next(). This fixes BUG#35477.
      (bk trigger: file as fix for BUG#35478).
      2951f00b
  26. 18 May, 2008 1 commit
    • gshchepa/uchum@host.loc's avatar
      Fixed bug#36676: multiupdate using LEFT JOIN updates only · 2459d3a9
      gshchepa/uchum@host.loc authored
                       first row or fails with an error:
        ERROR 1022 (23000): Can't write; duplicate key in table ''
      
      The server uses intermediate temporary table to store updated
      row data.  The first column of this table contains rowid.
      Current server implementation doesn't reset NULL flag of that
      column even if the server fills a column with rowid.
      To keep each rowid unique, there is an unique index.
      An insertion into an unique index takes into account NULL
      flag of key value and ignores real data if NULL flag is set.
      So, insertion of actually different rowids may lead to two
      kind of problems.  Visible effect of each of these problems
      depends on an initial engine type of temporary table:
      
      1. If multiupdate initially creates temporary table as
      a MyISAM table (a table contains blob columns, and the
      create_tmp_table function assumes, that this table is
      large), it inserts only one single row and updates
      only rows with one corresponding rowid. Other rows are
      silently ignored. 
      
      2. If multiupdate initially creates MEMORY temporary
      table, fills it with data and reaches size limit for
      MEMORY tables (max_heap_table_size), multiupdate
      converts MEMORY table into MyISAM table and fails
      with an error:
        ERROR 1022 (23000): Can't write; duplicate key in table ''
      
      
      Multiupdate has been fixed to update the NULL flag of
      temporary table rowid columns.
      2459d3a9
  27. 07 Apr, 2008 1 commit
  28. 01 Apr, 2008 1 commit
  29. 21 Mar, 2008 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug #26461: Intrinsic data type bool (1 byte) redefined to BOOL (4 bytes) · ff0aac17
      gkodinov/kgeorge@macbook.gmz authored
      The bool data type was redefined to BOOL (4 bytes on windows).
      Removed the #define and fixed some of the warnings that were uncovered
      by this.
      Note that the fix also disables 2 warnings :
      4800 : 'type' : forcing value to bool 'true' or 'false' (performance warning)
      4805: 'operation' : unsafe mix of type 'type' and type 'type' in operation
      
      These warnings will be handled in a separate bug, as they are performance related or bogus.
      
      Fixed to int the return type of functions that return more than 
      2 distinct values.
      ff0aac17
  30. 18 Mar, 2008 1 commit
    • svoj@mysql.com/june.mysql.com's avatar
      BUG#34768 - nondeterministic INSERT using LIMIT logged in stmt mode if · 6dfb184f
      svoj@mysql.com/june.mysql.com authored
                  binlog_format=mixed
      
      Statement-based replication of DELETE ... LIMIT, UPDATE ... LIMIT,
      INSERT ... SELECT ... LIMIT is not safe as order of rows is not
      defined.
      
      With this fix, we issue a warning that this statement is not safe to
      replicate in statement mode, or go to row-based mode in mixed mode.
      
      Note that we may consider a statement as safe if ORDER BY primary_key
      is present. However it may confuse users to see very similiar statements
      replicated differently.
      
      Note 2: regular UPDATE statement (w/o LIMIT) is unsafe as well, but
      this patch doesn't address this issue. See comment from Kristian
      posted 18 Mar 10:55.
      6dfb184f
  31. 19 Feb, 2008 2 commits
  32. 14 Feb, 2008 1 commit
  33. 12 Feb, 2008 1 commit
  34. 04 Feb, 2008 1 commit
    • aelkin/elkin@koti.dsl.inet.fi's avatar
      Bug#33329 extraneous ROLLBACK in binlog on connection · 7880fade
      aelkin/elkin@koti.dsl.inet.fi authored
                  does not use trans tables
      
      There had been two issues.
      Rollback statement was recorded in binlog even though a multi-update
      had not modified any non-transactional table.
      The reason for this artifact was a false initial value of multi_update::transactional_tables.
      Yet another artifact that explained on the bug page is that 
      `ha_autocommit_or_rollback' works differently depending on whether
      a transaction engine has been compiled in. 
      
      Fixed: with setting multi_update::transactional_tables to zero at initialization
      time. Multi-update on non-trans table won't cause ROLLBACK in binlog with
      either compilation option.
      
      The 2nd mentioned artifact comprises a self-standing issue (to be reported
      separately).
      7880fade
  35. 11 Jan, 2008 1 commit
  36. 20 Dec, 2007 1 commit
    • kostja@bodhi.(none)'s avatar
      A pre-requisite for the fix for Bug#12713 "Error in a stored function · dfe685e6
      kostja@bodhi.(none) authored
      called from a SELECT doesn't cause ROLLBACK of state"
      Make private all class handler methods (PSEA API) that may modify
      data. Introduce and deploy public ha_* wrappers for these methods in 
      all sql/.
      This necessary to keep track of all data modifications in sql/,
      which is in turn necessary to be able to optimize two-phase
      commit of those transactions that do not modify data.
      dfe685e6
  37. 13 Dec, 2007 1 commit
  38. 12 Dec, 2007 1 commit
    • kostja@bodhi.(none)'s avatar
      Bug#12713 "Error in a stored function called from a SELECT doesn't · ebb9c5d9
      kostja@bodhi.(none) authored
      cause ROLLBACK of statement", part 1. Review fixes.
      
      Do not send OK/EOF packets to the client until we reached the end of 
      the current statement.
      This is a consolidation, to keep the functionality that is shared by all 
      SQL statements in one place in the server.
      Currently this functionality includes:
      - close_thread_tables()
      - log_slow_statement().
      
      After this patch and the subsequent patch for Bug#12713, it shall also include:
      - ha_autocommit_or_rollback()
      - net_end_statement()
      - query_cache_end_of_result().
      
      In future it may also include:
      - mysql_reset_thd_for_next_command().
      ebb9c5d9
  39. 30 Oct, 2007 1 commit