An error occurred fetching the project authors.
  1. 27 May, 2010 1 commit
    • Dmitry Lenev's avatar
      A 5.1-only version of fix for bug #46947 "Embedded SELECT · 0a35e5bd
      Dmitry Lenev authored
      without FOR UPDATE is causing a lock".
      
      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 implements minimal version of the fix for the
      specific problem described in the bug-report which supposed
      to be not too risky for pushing into 5.1 tree.
      The 5.5 tree already contains a more appropriate solution
      which also addresses other related issues like bug 53921
      "Wrong locks for SELECTs used stored functions may lead
      to broken SBR".
      
      This patch tries to solve the problem by ensuring that
      TL_READ_DEFAULT lock which is set in the parser for
      tables participating in subqueries at open_tables()
      time is interpreted as TL_READ_NO_INSERT or TL_READ.
      TL_READ is used only if we know that this is a SELECT
      and that this particular table is not used by a stored
      function.
      
      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 (as well as in 5.0 and 5.1 before fix for bug 39843)
      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.
      
      The patch for bug 39843 broke this behaviour (which was not
      documented or tested), and started to use locking reads for
      all subqueries in SELECT ... FOR UPDATE/IN SHARE MODE.
      This patch restores 4.1 behaviour.
      
      This patch should be mostly null-merged into 5.5 tree.
      
      mysql-test/include/check_concurrent_insert.inc:
        Added auxiliary script which allows to check if statement
        reading table allows concurrent inserts in it.
      mysql-test/include/check_no_concurrent_insert.inc:
        Added auxiliary script which allows to check that statement
        reading table doesn't allow concurrent inserts in it.
      mysql-test/include/check_no_row_lock.inc:
        Added auxiliary script which allows to check if statement
        reading table doesn't take locks on its rows.
      mysql-test/include/check_shared_row_lock.inc:
        Added auxiliary script which allows to check if statement
        reading table takes shared locks on some of its rows.
      mysql-test/r/bug39022.result:
        After bug #46947 'Embedded SELECT without FOR UPDATE is
        causing a lock' was fixed test case for bug 39022 has to
        be adjusted in order to trigger execution path on which
        original problem was encountered.
      mysql-test/r/innodb_mysql_lock2.result:
        Added coverage for handling of locking in various cases when
        we read data from InnoDB tables (includes test case for
        bug #46947 'Embedded SELECT without FOR UPDATE is causing a
        lock').
      mysql-test/r/lock_sync.result:
        Added coverage for handling of locking in various cases when
        we read data from MyISAM tables.
      mysql-test/t/bug39022.test:
        After bug #46947 'Embedded SELECT without FOR UPDATE is
        causing a lock' was fixed test case for bug 39022 has to
        be adjusted in order to trigger execution path on which
        original problem was encountered.
      mysql-test/t/innodb_mysql_lock2.test:
        Added coverage for handling of locking in various cases when
        we read data from InnoDB tables (includes test case for
        bug #46947 'Embedded SELECT without FOR UPDATE is causing a
        lock').
      mysql-test/t/lock_sync.test:
        Added coverage for handling of locking in various cases when
        we read data from MyISAM tables.
      sql/mysql_priv.h:
        Function read_lock_type_for_table() now takes pointers to
        LEX and TABLE_LIST elements as its arguments since to
        correctly determine lock type it needs to know what
        statement is being performed and whether table element for
        which lock type to be determined belongs to prelocking list.
      sql/sql_base.cc:
        Changed read_lock_type_for_table() to return a weak TL_READ
        type of lock in cases when we are executing SELECT (and so
        won't update tables directly) and table doesn't belong to
        statement's prelocking list and thus can't be used by a
        stored function. It is OK to do so since in this case table
        won't be used by statement or function call which will be
        written to the binary log, so serializability requirements
        for it can be relaxed.
        One of results from this change is that SELECTs on InnoDB
        tables no longer takes shared row locks for tables which
        are used in subqueries (i.e. bug #46947 is fixed).
        Another result is that for similar SELECTs on MyISAM tables
        concurrent inserts are allowed.
        In order to implement this change signature of
        read_lock_type_for_table() function was changed to
        take pointers to LEX and TABLE_LIST objects.
      sql/sql_update.cc:
        Function read_lock_type_for_table() now takes pointers to
        LEX and TABLE_LIST elements as its arguments since to
        correctly determine lock type it needs to know what
        statement is being performed and whether table element for
        which lock type to be determined belongs to prelocking list.
      0a35e5bd
  2. 25 May, 2010 1 commit
    • Alexey Kopytov's avatar
      Bug #53830: !table || (!table->read_set || · 1d0acc77
      Alexey Kopytov authored
                   bitmap_is_set(table->read_set, field_index))
      
      UPDATE on an InnoDB table modifying the same index that is used
      to satisfy the WHERE condition could trigger a debug assertion
      under some circumstances.
      
      Since for engines with the HA_PRIMARY_KEY_IN_READ_INDEX flag
      set results of an index scan on a secondary index are appended
      by the primary key value, if a query involves only columns from
      the primary key and a secondary index, the latter is considered
      to be covering.
      
      That tricks mysql_update() to mark for reading only columns
      from the secondary index when it does an index scan to retrieve
      rows to update in case a part of that key is also being
      updated. However, there may be other columns in WHERE that are
      part of the primary key, but not the secondary one.
      
      What we actually want to do in this case is to add index
      columns to the existing WHERE columns bitmap rather than
      replace it.
      
      mysql-test/r/innodb_mysql.result:
        Test case for bug #53830.
      mysql-test/t/innodb_mysql.test:
        Test case for bug #53830.
      sql/sql_update.cc:
        Add index columns to the read_set bitmap, don't replace it.
      sql/table.cc:
        Added a new add_read_columns_used_by_index() function to 
        st_table.
      sql/table.h:
        Added a new add_read_columns_used_by_index() function to 
        st_table.
      1d0acc77
  3. 12 May, 2010 1 commit
    • Staale Smedseng's avatar
      Bug #49756 Rows_examined is always 0 in the slow query log for · 330864fc
      Staale Smedseng authored
      update statements
            
      Only SELECT statements report any examined rows in the slow
      log. Slow UPDATE, DELETE and INSERT statements report 0 rows
      examined, unless the statement has a condition including a
      SELECT substatement.
            
      This patch adds counting of examined rows for the UPDATE and
      DELETE statements. An INSERT ... VALUES statement will still 
      not report any rows as examined.
      
      
      
      sql/sql_class.h:
        Added more docs for THD::examined_row_count.
      sql/sql_delete.cc:
        Add incrementing thd->examined_row_count.
      sql/sql_update.cc:
        Add incrementing thd->examined_row_count.
      330864fc
  4. 11 May, 2010 1 commit
    • Martin Hansson's avatar
      Bug#48157: crash in Item_field::used_tables · 79e60f0a
      Martin Hansson authored
            
      MySQL handles the join syntax "JOIN ... USING( field1,
      ... )" and natural joins by building the same parse tree as
      a corresponding join with an "ON t1.field1 = t2.field1 ..."
      expression would produce. This parse tree was not cleaned up
      properly in the following scenario. If a thread tries to
      lock some tables and finds that the tables were dropped and
      re-created while waiting for the lock, it cleans up column
      references in the statement by means a per-statement free
      list. But if the statement was part of a stored procedure,
      column references on the stored procedure's free list
      weren't cleaned up and thus contained pointers to freed
      objects.
            
      Fixed by adding a call to clean up the current prepared
      statement's free list.
      
      This is a backport from MySQL 5.1
      79e60f0a
  5. 28 Apr, 2010 1 commit
    • Georgi Kodinov's avatar
      Bug #47453: InnoDB incorrectly changes TIMESTAMP columns when JOINed · 4d0e9957
      Georgi Kodinov authored
      during an UPDATE
      
      Extended the fix for bug 29310 to multi-table update:
      
      When a table is being updated it has two set of fields - fields required for
      checks of conditions and fields to be updated. A storage engine is allowed
      not to retrieve columns marked for update. Due to this fact records can't
      be compared to see whether the data has been changed or not. This makes the
      server always update records independently of data change.
        
      Now when an auto-updatable timestamp field is present and server sees that
      a table handle isn't going to retrieve write-only fields then all of such
      fields are marked as to be read to force the handler to retrieve them.
      4d0e9957
  6. 22 Feb, 2010 1 commit
    • Staale Smedseng's avatar
      Bug #43414 Parenthesis (and other) warnings compiling · 57a40848
      Staale Smedseng authored
      MySQL with gcc 4.3.2
            
      This is the final patch in the context of this bug. 
      
      cmd-line-utils/readline/rlmbutil.h:
        Changed in a previous patch, reverted by a backport.
      cmd-line-utils/readline/text.c:
        Static var initialization.
      extra/yassl/include/yassl_error.hpp:
        SetErrorString handles errors outside of the YasslError
        enum.
      extra/yassl/src/ssl.cpp:
        SetErrorString handles errors outside of the YasslError
        enum.
      extra/yassl/src/yassl_error.cpp:
        SetErrorString handles errors outside of the YasslError
        enum.
      57a40848
  7. 09 Feb, 2010 1 commit
    • Sergey Vojtovich's avatar
      BUG#49902 - SELECT returns incorrect results · 0897669c
      Sergey Vojtovich authored
      Queries optimized with GROUP_MIN_MAX didn't cleanup KEYREAD
      optimization properly. As a result subsequent queries may
      return incomplete rows (fields are initialized to default
      values).
      
      mysql-test/r/group_min_max.result:
        A test case for BUG#49902.
      mysql-test/t/group_min_max.test:
        A test case for BUG#49902.
      sql/opt_range.cc:
        Refactor of KEYREAD optimization switch so that KEYREAD
        handler state is in sync with st_table::key_read flag.
        
        All SQL code is supposed to switch KEYREAD optimization
        via st_table::set_keyread().
      sql/opt_sum.cc:
        Refactor of KEYREAD optimization switch so that KEYREAD
        handler state is in sync with st_table::key_read flag.
        
        All SQL code is supposed to switch KEYREAD optimization
        via st_table::set_keyread().
      sql/sql_select.cc:
        Refactor of KEYREAD optimization switch so that KEYREAD
        handler state is in sync with st_table::key_read flag.
        
        All SQL code is supposed to switch KEYREAD optimization
        via st_table::set_keyread().
      sql/sql_update.cc:
        Refactor of KEYREAD optimization switch so that KEYREAD
        handler state is in sync with st_table::key_read flag.
        
        All SQL code is supposed to switch KEYREAD optimization
        via st_table::set_keyread().
      sql/table.cc:
        Refactor of KEYREAD optimization switch so that KEYREAD
        handler state is in sync with st_table::key_read flag.
        
        All SQL code is supposed to switch KEYREAD optimization
        via st_table::set_keyread().
      sql/table.h:
        Refactor of KEYREAD optimization switch so that KEYREAD
        handler state is in sync with st_table::key_read flag.
        
        All SQL code is supposed to switch KEYREAD optimization
        via st_table::set_keyread().
      0897669c
  8. 10 Feb, 2010 1 commit
    • Martin Hansson's avatar
      Bug#49534: multitable IGNORE update with sql_safe_updates · 630fa243
      Martin Hansson authored
      error causes debug assertion
      
      The IGNORE option of the multiple-table UPDATE command was
      not intended to suppress errors caused by the
      sql_safe_updates mode. This flag will raise an error if the
      execution of UPDATE does not use a key for row retrieval,
      and should continue do so regardless of the IGNORE option.
      
      However the implementation of IGNORE does not support
      exceptions to the rule; it always converts errors to
      warnings and cannot be extended. The Internal_error_handler
      interface offers the infrastructure to handle individual
      errors, making sure that the error raised by
      sql_safe_updates is not silenced.
      
      Fixed by implementing an Internal_error_handler and using it
      for UPDATE IGNORE commands.
      630fa243
  9. 24 Jan, 2010 1 commit
  10. 12 Jan, 2010 1 commit
    • Martin Hansson's avatar
      Bug#48157: crash in Item_field::used_tables · c8b5804f
      Martin Hansson authored
      MySQL handles the join syntax "JOIN ... USING( field1,
      ... )" and natural joins by building the same parse tree as
      a corresponding join with an "ON t1.field1 = t2.field1 ..."
      expression would produce. This parse tree was not cleaned up
      properly in the following scenario. If a thread tries to
      lock some tables and finds that the tables were dropped and
      re-created while waiting for the lock, it cleans up column
      references in the statement by means a per-statement free
      list. But if the statement was part of a stored procedure,
      column references on the stored procedure's free list weren't
      cleaned up and thus contained pointers to freed objects.
      
      Fixed by adding a call to clean up the current prepared
      statement's free list.
      
      
      mysql-test/r/sp_sync.result:
        Bug#48157: Test case
      mysql-test/t/sp_sync.test:
        Bug#48157: Test result
      sql/item.h:
        Bug#48157: Commented field.
      sql/sql_parse.cc:
        Bug#48157: Commented function.
      sql/sql_update.cc:
        Bug#48157: fix
      c8b5804f
  11. 13 Dec, 2009 1 commit
    • unknown's avatar
      This is a patch for Bug#48500 · 71c54b8c
      unknown authored
      5.0 buffer overflow for ER_UPDATE_INFO, or truncated info message in 5.1
            
      5.0.86 has a buffer overflow/crash, and 5.1.40 has a truncated message.
            
      errmsg.txt contains this:
            
      ER_UPDATE_INFO
      rum "Linii identificate (matched): %ld  Schimbate: %ld  Atentionari 
      (warnings): %ld"
      When that is sprintf'd into a buffer of STRING_BUFFER_USUAL_SIZE size,
      a buffer overflow can happen.
            
      The solution to this is to use MYSQL_ERRMSG_SIZE for the buffer size, 
      instead of STRING_BUFFER_USUAL_SIZE. This will allow longer strings. 
      To avoid potential crashes, we will also use my_snprintf instead of
      sprintf.
      
      sql/sql_update.cc:
        sing MYSQL_ERRMSG_SIZE instead of STRING_BUFFER_USUAL_SIZE.
        Using my_snprintf instead of sprintf.
      71c54b8c
  12. 23 Oct, 2009 1 commit
    • Jon Olav Hauglid's avatar
      Bug #47919 assert in open_table during ALTER temporary table · 63541129
      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.
      63541129
  13. 16 Oct, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #40877: multi statement execution fails in 5.1.30 · 7b4ef910
      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.
      7b4ef910
  14. 28 Aug, 2009 1 commit
    • Staale Smedseng's avatar
      Bug #43414 Parenthesis (and other) warnings compiling MySQL · 1ba25ae4
      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.
      
      
      client/mysqlmanager-pwgen.c:
        A fix for warn_unused_result, adding fallback to use of
        srand()/rand() if /dev/random cannot be used. Also actually
        adds calls to rand() in the second branch so that it actually
        creates a random password.
      1ba25ae4
  15. 20 Aug, 2009 1 commit
    • Martin Hansson's avatar
      Bug#46616: Assertion `!table->auto_increment_field_not_null' on · e66fba53
      Martin Hansson authored
      view manipulations
            
      The bespoke flag was not properly reset after last call to 
      fill_record. Fixed by resetting in caller mysql_update.
      
      mysql-test/r/auto_increment.result:
        Bug#46616: Test result.
      mysql-test/t/auto_increment.test:
        Bug#46616: Test case.
      sql/sql_update.cc:
        Bug#46616: Fix.
      e66fba53
  16. 13 Jul, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #40113: Embedded SELECT inside UPDATE or DELETE can timeout · 410e1a72
      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()
      
      mysql-test/r/bug40113.result:
        Bug #40013: test case
      mysql-test/r/group_min_max.result:
        Bug #40013: fixed a wrong test case
      mysql-test/t/bug40113-master.opt:
        Bug #40013: test case
      mysql-test/t/bug40113.test:
        Bug #40013: test case
      mysql-test/t/group_min_max.test:
        Bug #40013: fixed a wrong test case
      sql/sql_delete.cc:
        Bug #40113: check for errors evaluating the quick select
      sql/sql_update.cc:
        Bug #40113: check for errors evaluating the quick select
      410e1a72
  17. 18 Jun, 2009 1 commit
    • Alfranio Correia's avatar
      BUG#43929 binlog corruption when max_binlog_cache_size is exceeded · 3cf052b7
      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.
      3cf052b7
  18. 17 Jun, 2009 1 commit
    • Staale Smedseng's avatar
      Bug #43414 Parenthesis (and other) warnings compiling MySQL · 3b0e6e41
      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.
      3b0e6e41
  19. 10 Jun, 2009 1 commit
    • Staale Smedseng's avatar
      Bug #43414 Parenthesis (and other) warnings compiling MySQL · a1035097
      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.
      a1035097
  20. 30 May, 2009 1 commit
    • He Zhenxing's avatar
      BUG#41948 Query_log_event constructor needlessly contorted · abf5f8da
      He Zhenxing authored
      Make the caller of Query_log_event, Execute_load_log_event
      constructors and THD::binlog_query to provide the error code
      instead of having the constructors to figure out the error code.
      
      sql/log_event.cc:
        Changed constructors of Query_log_event and Execute_load_log_event to accept the error code argument instead of figuring it out by itself
      sql/log_event.h:
        Changed constructors of Query_log_event and Execute_load_log_event to accept the error code argument
      abf5f8da
  21. 05 May, 2009 1 commit
    • Martin Hansson's avatar
      Bug#43580: Issue with Innodb on multi-table update · 391364fa
      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.
      
      
      mysql-test/r/innodb_mysql.result:
        Bug#43580: Test result.
      mysql-test/suite/rpl/r/rpl_slave_skip.result:
        Bug#43580: Changed test result. The InnoDB result is now what it would have been on MyISAM.
      mysql-test/t/innodb_mysql.test:
        Bug#43580: Test case.
      sql/sql_base.cc:
        Bug#43580: Added a word of caution about using tmp_set here.
      sql/sql_update.cc:
        Bug#43580: Fix.
        Calls to TABLE::mark_columns_needed_for_update() are moved
        from mysql_multi_update_prepare() and right before the decison
        to do on-the-fly updates to the place where we do (or don't do)
        on-the-fly updates.
      391364fa
  22. 04 May, 2009 1 commit
  23. 27 Mar, 2009 1 commit
    • He Zhenxing's avatar
      BUG#37145 Killing a statement doing DDL may log binlog event with error code 1053 · 51a91166
      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.
      51a91166
  24. 05 Mar, 2009 1 commit
  25. 05 Feb, 2009 1 commit
    • Gleb Shchepa's avatar
      Bug #39265: fix for the bug 33699 should be reverted · b9d02d46
      Gleb Shchepa authored
      Documented behaviour was broken by the patch for bug 33699
      that actually is not a bug.
      
      This fix reverts patch for bug 33699 and reverts the
      UPDATE of NOT NULL field with NULL query to old
      behavior.
      
      
      mysql-test/extra/rpl_tests/rpl_extraMaster_Col.test:
        Bug #39265: fix for the bug 33699 should be reverted
      mysql-test/include/ps_modify.inc:
        Bug #39265: fix for the bug 33699 should be reverted
      mysql-test/r/auto_increment.result:
        Bug #39265: fix for the bug 33699 should be reverted
      mysql-test/r/csv_not_null.result:
        Bug #39265: fix for the bug 33699 should be reverted
      mysql-test/r/null.result:
        Bug #39265: fix for the bug 33699 should be reverted
      mysql-test/r/ps_2myisam.result:
        Bug #39265: fix for the bug 33699 should be reverted
      mysql-test/r/ps_3innodb.result:
        Bug #39265: fix for the bug 33699 should be reverted
      mysql-test/r/ps_4heap.result:
        Bug #39265: fix for the bug 33699 should be reverted
      mysql-test/r/ps_5merge.result:
        Bug #39265: fix for the bug 33699 should be reverted
      mysql-test/r/warnings.result:
        Bug #39265: fix for the bug 33699 should be reverted
      mysql-test/suite/ndb/r/ps_7ndb.result:
        Bug #39265: fix for the bug 33699 should be reverted
      mysql-test/suite/rpl/r/rpl_extraColmaster_innodb.result:
        Bug #39265: fix for the bug 33699 should be reverted
      mysql-test/suite/rpl/r/rpl_extraColmaster_myisam.result:
        Bug #39265: fix for the bug 33699 should be reverted
      mysql-test/suite/rpl/t/rpl_err_ignoredtable.test:
        Bug #39265: fix for the bug 33699 should be reverted
      mysql-test/t/auto_increment.test:
        Bug #39265: fix for the bug 33699 should be reverted
      mysql-test/t/csv_not_null.test:
        Bug #39265: fix for the bug 33699 should be reverted
      mysql-test/t/null.test:
        Bug #39265: fix for the bug 33699 should be reverted
      mysql-test/t/warnings.test:
        Bug #39265: fix for the bug 33699 should be reverted
      sql/sql_update.cc:
        Bug #39265: fix for the bug 33699 should be reverted
      b9d02d46
  26. 28 Nov, 2008 1 commit
    • Gleb Shchepa's avatar
      Bug #40745: Error during WHERE clause calculation in UPDATE · d15cbc1a
      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.
      
      
      mysql-test/r/update.result:
        Added test case for bug #40745.
      mysql-test/t/update.test:
        Added test case for bug #40745.
      sql/sql_update.cc:
        Bug #40745: Error during WHERE clause calculation in UPDATE
                    leads to an assertion failure
        
        The mysql_update function has been updated to take into account
        the status of invoked stored functions before setting the status
        of whole UPDATE query to OK.
      d15cbc1a
  27. 27 Nov, 2008 1 commit
    • Sergey Glukhov's avatar
      Bug#37460 Assertion failed: !table->file || table->file->inited == handler::NONE · 89d04406
      Sergey Glukhov authored
      enable uncacheable flag if we update a view with check option
      and check option has a subselect, otherwise, the check option
      can be evaluated after the subselect was freed as independent
      (See full_local in JOIN::join_free())
      
      
      mysql-test/r/subselect.result:
        test result
      mysql-test/t/subselect.test:
        test case
      sql/mysql_priv.h:
        added UNCACHEABLE_CHECKOPTION flag
      sql/sql_update.cc:
        enable uncacheable flag if we update a view with check option
        and check option has a subselect, otherwise, the check option
        can be evaluated after the subselect was freed as independent
        (See full_local in JOIN::join_free())
      89d04406
  28. 10 Nov, 2008 1 commit
  29. 09 Oct, 2008 1 commit
    • Gleb Shchepa's avatar
      Bug#38499: flush tables and multitable table update with · a83f5b18
      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.
      
      
      mysql-test/r/lock_multi.result:
        Added test case for bug #38499.
      mysql-test/t/lock_multi.test:
        Added test case for bug #38499.
      sql/sql_union.cc:
        Bug#38499: flush tables and multitable table update with
                   derived table cause crash
        
        Obsolete assertion has been removed.
      sql/sql_update.cc:
        Bug#38499: flush tables and multitable table update with
                   derived table cause crash
        
        Extra cleanup for derived tables has been added:
        1) unit.cleanup(),
        2) unit->reinit_exec_mechanism().
      a83f5b18
  30. 07 Oct, 2008 1 commit
    • Gleb Shchepa's avatar
      Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while · f48b42e7
      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*.
      
      
      mysql-test/r/lock_multi.result:
        Added test case for bug #38691.
      mysql-test/t/lock_multi.test:
        Added test case for bug #38691.
      sql/item.cc:
        Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
                  ``FLUSH TABLES WITH READ LOCK''
        
        The Item_field constructor has been modified to allocate
        and copy original database/table/field names always (not
        during PS preparation/1st execution only), because
        an initialization of Item_field items with a pointer to
        short-living Field structures is a common practice.
      sql/sql_base.cc:
        Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
                  ``FLUSH TABLES WITH READ LOCK''
        
        1) Type adjustment for Natural_join_column::table_field
           (Field to Item_field);
        2) The setup_natural_join_row_types function has been
           updated to take into account new
           first_natural_join_processing flag to skip unnecessary
           reinitialization of Natural_join_column::join_columns
           during table reopening after lock_tables() failure
           (like the 'first_execution' flag for PS).
      sql/sql_lex.cc:
        Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
                  ``FLUSH TABLES WITH READ LOCK''
        
        Initialization of the new
        st_select_lex::first_natural_join_processing flag has
        been added.
      sql/sql_lex.h:
        Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
                  ``FLUSH TABLES WITH READ LOCK''
        
        The st_select_lex::first_natural_join_processing flag
        has been added to skip unnecessary rebuilding of
        NATURAL/USING JOIN structures during table reopening
        after lock_tables failure.
      sql/sql_update.cc:
        Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
                  ``FLUSH TABLES WITH READ LOCK''
        
        Extra cleanup calls have been added to reset
        Natural_join_column::table_field items.
      sql/table.cc:
        Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
                  ``FLUSH TABLES WITH READ LOCK''
        
        Type adjustment for Natural_join_column::table_field
        (Field to Item_field).
      sql/table.h:
        Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
                  ``FLUSH TABLES WITH READ LOCK''
        
        Type of the Natural_join_column::table_field field has
        been changed from Field that points into short-living
        TABLE memory to long-living Item_field that can be
        linked to (fixed) reopened table.
      f48b42e7
  31. 29 Sep, 2008 1 commit
    • Davi Arnaut's avatar
      Bug#34306: Can't make copy of log tables when server binary log is enabled · 0406d409
      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.
      
      include/thr_lock.h:
        Introduce yet another lock type that my get upgraded depending
        on the binary log format. This is not a optimal solution but
        can be easily improved later.
      mysql-test/r/log_tables.result:
        Add test case result for Bug#34306
      mysql-test/suite/binlog/r/binlog_stm_row.result:
        Add test case result for Bug#34306
      mysql-test/suite/binlog/t/binlog_stm_row.test:
        Add test case for Bug#34306
      mysql-test/t/log_tables.test:
        Add test case for Bug#34306
      sql/lock.cc:
        Assert that TL_READ_DEFAULT is not a real lock type.
      sql/mysql_priv.h:
        Export new function.
      sql/mysqld.cc:
        Remove using_update_log.
      sql/sql_base.cc:
        Introduce function that returns the appropriate read lock type
        depending on how the statement is going to be replicated. It will
        only take a TL_READ_NO_INSERT log if the binary is enabled and the
        binary log format is statement-based and the table is not a log table.
      sql/sql_parse.cc:
        Remove using_update_log.
      sql/sql_update.cc:
        Use new function to choose read lock type.
      sql/sql_yacc.yy:
        The lock type is now decided at open_tables time. This old behavior was
        actually misleading as the binary log format can be dynamically switched
        and this would not change for statements that have already been parsed
        when the binary log format is changed (ie: prepared statements).
      0406d409
  32. 26 Aug, 2008 1 commit
  33. 31 Jul, 2008 1 commit
    • He Zhenxing's avatar
      BUG#37051 Replication rules not evaluated correctly · a018e98c
      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.
      
      
      sql/sql_class.h:
        add member table_map_for_update to THD
      sql/sql_parse.cc:
        check filter rules by using table_map_for_update value
      sql/sql_update.cc:
        save the value of table_map_for_update
      a018e98c
  34. 15 Jul, 2008 1 commit
    • Sergey Petrunia's avatar
      BUG#35478: sort_union() returns bad data when sort_buffer_size is hit · 62513bb1
      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).
      
      sql/filesort.cc:
        BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
        - make find_all_keys() use quick->get_next() instead of init_read_record(r)/r.read_record() calls
        - added dbug printout
      sql/mysql_priv.h:
        BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
        - Added parameter to init_read_record
      sql/opt_range.cc:
        BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
        - 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().
      sql/records.cc:
        BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
        - Added disable_rr_cache parameter to init_read_record
        - Added comment
      sql/sql_acl.cc:
        BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
        - Added parameter to init_read_record
      sql/sql_delete.cc:
        BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
        - Added parameter to init_read_record
      sql/sql_help.cc:
        BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
        - Added parameter to init_read_record
      sql/sql_select.cc:
        BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
        - Added parameter to init_read_record
      sql/sql_table.cc:
        BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
        - Added parameter to init_read_record
      sql/sql_udf.cc:
        BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
        - Added parameter to init_read_record
      sql/sql_update.cc:
        BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
        - Added parameter to init_read_record
      62513bb1
  35. 18 May, 2008 1 commit
    • unknown's avatar
      Fixed bug#36676: multiupdate using LEFT JOIN updates only · 29e7fa25
      unknown 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.
      
      
      
      mysql-test/r/multi_update_tiny_hash.result:
        Added test case for bug#36676.
      mysql-test/t/multi_update_tiny_hash-master.opt:
        Added test case for bug#36676.
      mysql-test/t/multi_update_tiny_hash.test:
        Added test case for bug#36676.
      sql/sql_update.cc:
        Fixed bug#36676: multiupdate using LEFT JOIN updates only
                         first row or fails with an error:
          ERROR 1022 (23000): Can't write; duplicate key in table ''
        
        The multi_update::send_data method has been modified to reset null bits of
        fields containing rowids.
      29e7fa25
  36. 07 Apr, 2008 1 commit
  37. 01 Apr, 2008 1 commit
  38. 21 Mar, 2008 1 commit
    • unknown's avatar
      Bug #26461: Intrinsic data type bool (1 byte) redefined to BOOL (4 bytes) · cebb6727
      unknown 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.
      
      
      CMakeLists.txt:
        Bug #26461: disable the C4800 and C4805 warnings temporarily
      include/config-win.h:
        Bug #26461: 
         - no need for this define for Windows.
         - windows C++ compilers have a bool type
      include/my_global.h:
        Bug #26461: removed bool_defined (no longer needed)
      sql/handler.h:
        Bug #26461: bool functions must return boolean values
      sql/mysql_priv.h:
        Bug #26461: fixed return type of functions that return more than
        2 distinct values.
      sql/procedure.h:
        Bug #26461: fixed return type of functions that return more than
        2 distinct values.
      sql/sql_acl.cc:
        Bug #26461: fixed return type of functions that return more than
        2 distinct values.
      sql/sql_acl.h:
        Bug #26461: fixed return type of functions that return more than
        2 distinct values.
      sql/sql_analyse.cc:
        Bug #26461: fixed return type of functions that return more than
        2 distinct values.
      sql/sql_analyse.h:
        Bug #26461: fixed return type of functions that return more than
        2 distinct values.
      sql/sql_base.cc:
        Bug #26461: fixed return type of functions that return more than
        2 distinct values.
      sql/sql_db.cc:
        Bug #26461: fixed return type of functions that return more than
        2 distinct values.
      sql/sql_delete.cc:
        Bug #26461: fixed return type of functions that return more than
        2 distinct values.
      sql/sql_load.cc:
        Bug #26461: fixed return type of functions that return more than
        2 distinct values.
      sql/sql_parse.cc:
        Bug #26461: fixed return type of functions that return more than
        2 distinct values.
      sql/sql_prepare.cc:
        Bug #26461: fixed return type of functions that return more than
        2 distinct values.
      sql/sql_update.cc:
        Bug #26461: fixed return type of functions that return more than
        2 distinct values.
      cebb6727
  39. 18 Mar, 2008 1 commit
    • unknown's avatar
      BUG#34768 - nondeterministic INSERT using LIMIT logged in stmt mode if · 1626b42c
      unknown 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.
      
      
      mysql-test/suite/binlog/r/binlog_stm_ps.result:
        Updated a test case according to fix for BUG#34768:
        INSERT ... SELECT ... LIMIT is now replicated in row mode.
      mysql-test/suite/binlog/r/binlog_unsafe.result:
        A test case for BUG#34768.
      mysql-test/suite/binlog/t/binlog_unsafe.test:
        A test case for BUG#34768.
      sql/sql_delete.cc:
        Statement-based replication of DELETE ... LIMIT is not safe as order of
        rows is not defined, so in mixed mode we go to row-based.
      sql/sql_insert.cc:
        Statement-based replication of INSERT ... SELECT ... LIMIT is not safe
        as order of rows is not defined, so in mixed mode we go to row-based.
      sql/sql_update.cc:
        Statement-based replication of UPDATE ... LIMIT is not safe as order of
        rows is not defined, so in mixed mode we go to row-based.
      1626b42c
  40. 19 Feb, 2008 1 commit