An error occurred fetching the project authors.
  1. 13 Dec, 2007 3 commits
  2. 12 Dec, 2007 2 commits
    • 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
    • aelkin/elkin@koti.dsl.inet.fi's avatar
      Bug#31552 Replication breaks when deleting rows from out-of-sync table · d8d6db6f
      aelkin/elkin@koti.dsl.inet.fi authored
          without PK
      Bug#31609 Not all RBR slave errors reported as errors
      bug#32468 delete rows event on a table with foreign key constraint fails
      
      The first two bugs comprise idempotency issues.
      First, there was no error code reported under conditions of the bug
      description although the slave sql thread halted.
      Second, executions were different with and without presence of prim key in
      the table.
      Third, there was no way to instruct the slave whether to ignore an error
      and skip to the following event or to halt.
      Fourth, there are handler errors which might happen due to idempotent
      applying of binlog but those were not listed among the "idempotent" error
      list.
      
      All the named issues are addressed.
      Wrt to the 3rd, there is the new global system variable, changeble at run
      time, which controls the slave sql thread behaviour.
      The new variable allows further extensions to mimic the sql_mode
      session/global variable.
      To address the 4th, the new bug#32468 had to be fixed as it was staying
      in the way.
      d8d6db6f
  3. 26 Nov, 2007 1 commit
    • kaa@polly.(none)'s avatar
      5.0 version of the fix for bug #9481: mysql_insert_id() returns 0 after · 24c9d864
      kaa@polly.(none) authored
      insert ... select.
      
      The 5.0 manual page for mysql_insert_id() does not mention anything
      about INSERT ... SELECT, though its current behavior is incosistent
      with what the manual says about the plain INSERT.
      
      Fixed by changing the AUTO_INCREMENT and mysql_insert_id() handling
      logic in INSERT ... SELECT to be consistent with the INSERT behavior,
      the manual, and the changes in 5.1 introduced by WL3146:
      
      
      - mysql_insert_id() now returns the first automatically generated
      AUTO_INCREMENT value that was successfully inserted by INSERT ... SELECT
      
      -  if an INSERT ... SELECT statement is executed, and no automatically
      generated value is successfully inserted, mysql_insert_id() now returns
      the ID of the last inserted row.
      24c9d864
  4. 19 Nov, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#30384: Having SQL_BUFFER_RESULT option in the CREATE .. KEY(..) .. SELECT · da7470af
      evgen@moonbone.local authored
      led to creating corrupted index.
      
      Corrected fix. The new method called prepare2 is added to the select_create
      class. As all preparations are done by the select_create::prepare function
      it doesn't do anything. Slightly changed algorithm of calling the 
      start_bulk_insert function. Now it's called from the select_insert::prepare2
      function when the SQL_BUFFER_RESULT flags is set.
      The is_bulk_insert_mode flag is removed as it is not needed anymore.
      da7470af
  5. 10 Nov, 2007 2 commits
    • serg@janus.mylan's avatar
      bad merge fixed · abf2ae83
      serg@janus.mylan authored
      abf2ae83
    • tnurnberg@mysql.com/white.intern.koehntopp.de's avatar
      Bug#31700: thd->examined_row_count not incremented for 'const' type queries · 8a5e621f
      UNIQUE (eq-ref) lookups result in table being considered as a "constant" table.
      Queries that consist of only constant tables are processed in do_select() in a
      special way that doesn't invoke evaluate_join_record(), and therefore doesn't
      increase the counters join->examined_rows and join->thd->row_count.
      
      The patch increases these counters in this special case.
      
      NOTICE:
      This behavior seems to contradict what the documentation says in Sect. 5.11.4:
      "Queries handled by the query cache are not added to the slow query log, nor
      are queries that would not benefit from the presence of an index because the
      table has zero rows or one row."
      
      No test case in 5.0 as issue shows only in slow query log, and other counters
      can give subtly different values (with regard to counting in create_sort_index(),
      synthetic rows in ROLLUP, etc.).
      8a5e621f
  6. 31 Oct, 2007 1 commit
  7. 30 Oct, 2007 2 commits
  8. 25 Oct, 2007 1 commit
  9. 23 Oct, 2007 1 commit
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #31663: if the FIELDS TERMINATED BY string · 5adc332c
      gshchepa/uchum@gleb.loc authored
      in the SELECT INTO OUTFILE clause starts with a special
      character (one of n, t, r, b, 0, Z or N) and ENCLOSED BY
      is empty, every occurrence of this character within a
      field value is duplicated.
      
      Duplication has been avoided.
      New warning message has been added: "First character of
      the FIELDS TERMINATED string is ambiguous; please use
      non-optional and non-empty FIELDS ENCLOSED BY".
      5adc332c
  10. 19 Oct, 2007 1 commit
  11. 16 Oct, 2007 1 commit
  12. 13 Oct, 2007 1 commit
    • aelkin/elkin@koti.dsl.inet.fi's avatar
      Bug #29136 erred multi-delete on trans table does not rollback the statement · ed0ab76e
      aelkin/elkin@koti.dsl.inet.fi authored
      similar to bug_27716, but it was stressed on in the synopsis on that there is another
      side of the artifact affecting behaviour in transaction.
      
      Fixed with deploying multi_delete::send_error() - otherwise never called - and refining its logic
      to perform binlogging job if needed.
      
      The changeset includes the following side effects:
      - added tests to check bug_23333's scenarios on the mixture of tables for multi_update;
      - fixes bug@30763 with two-liner patch and a test coinciding to one added for bug_23333.
      ed0ab76e
  13. 03 Oct, 2007 1 commit
    • sven@murkla.(none)'s avatar
      BUG#30752 rpl_dual_pos_advance valgrind (jump depends on uninitialized LOG_INFO) · 5daff654
      sven@murkla.(none) authored
      Problem: one thread could read uninitialized memory from (the stack of) another
      thread.
      Fix: swapped order of initializing the memory and making it available to the
      other thread.
      Fix: put lock around the statement that makes the memory available to the other
      thread.
      Fix: all fields of the struct are now initialized in the constructor, to avoid
      future problems.
      5daff654
  14. 28 Sep, 2007 1 commit
  15. 21 Sep, 2007 1 commit
    • evgen@sunlight.local's avatar
      Bug#30384: Having SQL_BUFFER_RESULT option in the CREATE .. KEY(..) .. SELECT · bb5cdfb8
      evgen@sunlight.local authored
      led to creating corrupted index.
      
      While execution of the  CREATE .. SELECT SQL_BUFFER_RESULT statement the 
      engine->start_bulk_insert function was called twice. On the first call
      On the first call MyISAM disabled all non-unique indexes and on the second
      call it decides to not re-enable them because all indexes was disabled.
      Due to this no indexes was actually created during CREATE TABLE thus
      producing crashed table.
      
      Now the select_inset class has is_bulk_insert_mode flag which prevents
      calling the start_bulk_insert function twice.
      The flag is set in the select_create::prepare, select_insert::prepare2
      functions and the select_insert class constructor.
      The flag is reset in the select_insert::send_eof function.
      bb5cdfb8
  16. 31 Aug, 2007 1 commit
    • anozdrin/alik@ibm.opbmk's avatar
      Fix for BUG#25843: changing default database between PREPARE and EXECUTE · d6f94b06
      anozdrin/alik@ibm.opbmk authored
      of statement breaks binlog.
      
      There were two problems discovered by this bug:
      
        1. Default (current) database is not fixed at the creation time.
           That leads to wrong output of DATABASE() function.
      
        2. Database attributes (@@collation_database) are not fixed at
           the creation time. That leads to wrong resultset.
      
      Binlog breakage and Query Cache wrong output happened because of
      the first problem.
      
      The fix is to remember the current database at the PREPARE-time and
      set it each time at EXECUTE.
      d6f94b06
  17. 30 Aug, 2007 1 commit
  18. 16 Aug, 2007 1 commit
  19. 13 Aug, 2007 1 commit
    • monty@mysql.com/nosik.monty.fi's avatar
      Fixed a lot of compiler warnings and errors detected by Forte C++ on Solaris · e53a73e2
      monty@mysql.com/nosik.monty.fi authored
      Faster thr_alarm()
      Added 'Opened_files' status variable to track calls to my_open()
      Don't give warnings when running mysql_install_db
      Added option --source-install to mysql_install_db
      
      I had to do the following renames() as used polymorphism didn't work with Forte compiler on 64 bit systems
      index_read()      -> index_read_map()
      index_read_idx()  -> index_read_idx_map()
      index_read_last() -> index_read_last_map()
      e53a73e2
  20. 02 Aug, 2007 1 commit
  21. 01 Aug, 2007 2 commits
  22. 30 Jul, 2007 3 commits
    • gkodinov/kgeorge@magare.gmz's avatar
      (pushing for Andrei) · 9a0e6ec6
      gkodinov/kgeorge@magare.gmz authored
      Bug #27417 thd->no_trans_update.stmt lost value inside of SF-exec-stack
        
      Once had been set the flag might later got reset inside of a stored routine 
      execution stack.
      The reason was in that there was no check if a new statement started at time 
      of resetting.
      The artifact affects most of binlogable DML queries. Notice, that multi-update 
      is wrapped up within
        bug@27716 fix, multi-delete bug@29136.
        
      Fixed with saving parent's statement flag of whether the statement modified 
      non-transactional table, and unioning (merging) the value with that was gained 
      in mysql_execute_command.
        
      Resettling thd->no_trans_update members into thd->transaction.`member`;
      Asserting code;
      Effectively the following properties are held.
        
      1. At the end of a substatement thd->transaction.stmt.modified_non_trans_table
         reflects the fact if such a table got modified by the substatement.
         That also respects THD::really_abort_on_warnin() requirements.
      2. Eventually thd->transaction.stmt.modified_non_trans_table will be computed as
         the union of the values of all invoked sub-statements.
         That fixes this bug#27417;
      
      Computing of thd->transaction.all.modified_non_trans_table is refined to base to 
      the stmt's value for all the case including insert .. select statement which 
      before the patch had an extra issue bug@28960.
      Minor issues are covered with mysql_load, mysql_delete, and binloggin of insert in
      to temp_table select. 
        
      The supplied test verifies limitely, mostly asserts. The ultimate testing is defered
      for bug@13270, bug@23333.
      9a0e6ec6
    • evgen@moonbone.local's avatar
      Bug#24989: The DEADLOCK error is improperly handled by InnoDB. · 8de5603d
      evgen@moonbone.local authored
      When innodb detects a deadlock it calls ha_rollback_trans() to rollback the 
      main transaction. But such action isn't allowed from inside of triggers and
      functions. When it happen the 'Explicit or implicit commit' error is thrown
      even if there is no commit/rollback statements in the trigger/function. This
      leads to the user confusion.
      
      Now the convert_error_code_to_mysql() function doesn't call the 
      ha_rollback_trans() function directly but rather calls the
      mark_transaction_to_rollback function and returns an error.
      The sp_rcontext::find_handler() now doesn't allow errors to be caught by the
      trigger/function error handlers when the thd->is_fatal_sub_stmt_error flag
      is set. Procedures are still allowed to catch such errors.
      The sp_rcontext::find_handler function now accepts a THD handle as a parameter.
      The transaction_rollback_request and the is_fatal_sub_stmt_error flags are 
      added to the THD class. The are initialized by the THD class constructor.
      Now the ha_autocommit_or_rollback function rolls back main transaction
      when not in a sub statement and the thd->transaction_rollback_request
      is set.
      The THD::restore_sub_statement_state function now resets the 
      thd->is_fatal_sub_stmt_error flag on exit from a sub-statement.
      8de5603d
    • monty@mysql.com/nosik.monty.fi's avatar
      Slow query log to file now displays queries with microsecond precission · b16289a5
      monty@mysql.com/nosik.monty.fi authored
      --long-query-time is now given in seconds with microseconds as decimals
      --min_examined_row_limit added for slow query log
      long_query_time user variable is now double with 6 decimals
      Added functions to get time in microseconds
      Added faster time() functions for system that has gethrtime()  (Solaris)
      We now do less time() calls.
      Added field->in_read_set() and field->in_write_set() for easier field manipulation by handlers
      set_var.cc and my_getopt() can now handle DOUBLE variables.
      All time() calls changed to my_time()
      my_time() now does retry's if time() call fails.
      Added debug function for stopping in mysql_admin_table() when tables are locked
      Some trivial function and struct variable renames to avoid merge errors.
      Fixed compiler warnings
      Initialization of some time variables on windows moved to my_init() 
      b16289a5
  23. 27 Jul, 2007 2 commits
    • kostja@bodhi.(none)'s avatar
      A fix and a test case for Bug#24918 drop table and lock / inconsistent · 11c57540
      kostja@bodhi.(none) authored
      between perm and temp tables. Review fixes.
      
      The original bug report complains that if we locked a temporary table
      with LOCK TABLES statement, we would not leave LOCK TABLES mode
      when this temporary table is dropped.
      
      Additionally, the bug was escalated when it was discovered than
      when a temporary transactional table that was previously
      locked with LOCK TABLES statement was dropped, futher actions with
      this table, such as UNLOCK TABLES, would lead to a crash.
      
      The problem originates from incomplete support of transactional temporary
      tables. When we added calls to handler::store_lock()/handler::external_lock()
      to operations that work with such tables, we only covered the normal
      server code flow and did not cover LOCK TABLES mode. 
      In LOCK TABLES mode, ::external_lock(LOCK) would sometimes be called without
      matching ::external_lock(UNLOCK), e.g. when a transactional temporary table
      was dropped. Additionally, this table would be left in the list of LOCKed 
      TABLES.
      
      The patch aims to address this inadequacy. Now, whenever an instance
      of 'handler' is destroyed, we assert that it was priorly
      external_lock(UNLOCK)-ed. All the places that violate this assert
      were fixed.
      
      This patch introduces no changes in behavior -- the discrepancy in
      behavior will be fixed when we start calling ::store_lock()/::external_lock()
      for all tables, regardless whether they are transactional or not, 
      temporary or not.
      11c57540
    • malff/marcsql@weblab.(none)'s avatar
      WL#3984 (Revise locking of mysql.general_log and mysql.slow_log) · c7bbd891
      malff/marcsql@weblab.(none) authored
      Bug#25422 (Hang with log tables)
      Bug 17876 (Truncating mysql.slow_log in a SP after using cursor locks the
                thread)
      Bug 23044 (Warnings on flush of a log table)
      Bug 29129 (Resetting general_log while the GLOBAL READ LOCK is set causes
                 a deadlock)
      
      Prior to this fix, the server would hang when performing concurrent
      ALTER TABLE or TRUNCATE TABLE statements against the LOG TABLES,
      which are mysql.general_log and mysql.slow_log.
      
      The root cause traces to the following code:
      in sql_base.cc, open_table()
        if (table->in_use != thd)
        {
          /* wait_for_condition will unlock LOCK_open for us */
          wait_for_condition(thd, &LOCK_open, &COND_refresh);
        }
      The problem with this code is that the current implementation of the
      LOGGER creates 'fake' THD objects, like
      - Log_to_csv_event_handler::general_log_thd
      - Log_to_csv_event_handler::slow_log_thd
      which are not associated to a real thread running in the server,
      so that waiting for these non-existing threads to release table locks
      cause the dead lock.
      
      In general, the design of Log_to_csv_event_handler does not fit into the
      general architecture of the server, so that the concept of general_log_thd
      and slow_log_thd has to be abandoned:
      - this implementation does not work with table locking
      - it will not work with commands like SHOW PROCESSLIST
      - having the log tables always opened does not integrate well with DDL
      operations / FLUSH TABLES / SET GLOBAL READ_ONLY
      
      With this patch, the fundamental design of the LOGGER has been changed to:
      - always open and close a log table when writing a log
      - remove totally the usage of fake THD objects
      - clarify how locking of log tables is implemented in general.
      
      See WL#3984 for details related to the new locking design.
      
      Additional changes (misc bugs exposed and fixed):
      
      1)
      
      mysqldump which would ignore some tables in dump_all_tables_in_db(),
       but forget to ignore the same in dump_all_views_in_db().
      
      2)
      
      mysqldump would also issue an empty "LOCK TABLE" command when all the tables
      to lock are to be ignored (numrows == 0), instead of not issuing the query.
      
      3)
      
      Internal errors handlers could intercept errors but not warnings
      (see sql_error.cc).
      
      4)
      
      Implementing a nested call to open tables, for the performance schema tables,
      exposed an existing bug in remove_table_from_cache(), which would perform:
        in_use->some_tables_deleted=1;
      against another thread, without any consideration about thread locking.
      This call inside remove_table_from_cache() was not required anyway,
      since calling mysql_lock_abort() takes care of aborting -- cleanly -- threads
      that might hold a lock on a table.
      This line (in_use->some_tables_deleted=1) has been removed.
      c7bbd891
  24. 18 Jul, 2007 1 commit
  25. 16 Jul, 2007 1 commit
  26. 13 Jul, 2007 2 commits
    • kostja@bodhi.(none)'s avatar
      A follow up after the patch for Bug#21074 - even though · f5267530
      kostja@bodhi.(none) authored
      we now have exclusive name lock on the table name in mysql_rm_table_part2,
      we still should keep LOCK_open - some storage engines are not
      ready for locking scope change and assume that LOCK_open is kept.
      Still, the binary logging and query cache invalidation calls
      moved out of LOCK_open scope.
      Fixes some of the broken 5.1-runtime tests (tests break on asserts).
      f5267530
    • tnurnberg@sin.intern.azundris.com's avatar
      Bug#27198: Error returns from time() are ignored · 5cbe511f
      tnurnberg@sin.intern.azundris.com authored
      gettimeofday() can fail and presumably, so can time().
      Keep an eye on it.
      
      Since we have no data on this at all so far, we just
      retry on failure (and log the event), assuming that
      this is just an intermittant failure. This might of
      course hang the threat until we succeed. Once we know
      more about these failures, an appropriate more clever
      scheme may be picked (only try so many times per thread,
      etc., if that fails, return last "good" time() we got or
      some such).  Using sql_print_information() to log as this
      probably only occurs in high load scenarios where the debug-
      trace likely is disabled (or might interfere with testing
      the effect).  No test-case as this is a non-deterministic
      issue.
      5cbe511f
  27. 11 Jul, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #29325: · 015e1290
      gkodinov/kgeorge@magare.gmz authored
      By default MyISAM overwrites .MYD and .MYI files no 
      DATA DIRECTORY option is used. This can lead to two tables
      using the same .MYD and .MYI files (that can't be dropped).
      
      To prevent CREATE TABLE from overwriting a file a new option
      is introduced : keep_files_on_create
      When this is on the CREATE TABLE throws an error if either
      the .MYD or .MYI exists for a MyISAM table.
      The option is off by default (resulting in compatible behavior).
      015e1290
  28. 05 Jul, 2007 1 commit
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #29442. · c33f4d3d
      gshchepa/uchum@gleb.loc authored
      The SELECT INTO OUTFILE FIELDS ENCLOSED BY digit or minus sign,
      followed by the same LOAD DATA INFILE statement, used wrond encoding
      of non-string fields contained the enclosed character in their text
      representation.
      
      Example:
        SELECT 15, 9 INTO OUTFILE 'text' FIELDS ENCLOSED BY '5';
      
      Old encoded result in the text file:
        5155 595
               ^ was decoded as the 1st enclosing character of the 2nd field;
              ^ was skipped as garbage;
        ^    ^ was decoded as a pair of englosing characters of the 1st field;
            ^   was decoded as traling space of the first field;
          ^^ was decoded as a doubled enclosed character.
      
      New encoded result in the text file:
        51\55 595
        ^   ^ pair of enclosing characters of the 1st field;
          ^^ escaped enclosed character.
      c33f4d3d
  29. 04 Jul, 2007 1 commit
  30. 03 Jul, 2007 1 commit
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #29294. · dbe4fb94
      gshchepa/uchum@gleb.loc authored
      The `SELECT 'r' INTO OUTFILE ... FIELDS ENCLOSED BY 'r' ' statement
      encoded the 'r' string to a 4 byte string of value x'725c7272'
      (sequence of 4 characters: r\rr).
      The LOAD DATA statement decoded this string to a 1 byte string of
      value x'0d' (ASCII Carriage Return character) instead of the original
      'r' character.
      The same error also happened with the FIELDS ENCLOSED BY clause
      followed by special characters: 'n', 't', 'r', 'b', '0', 'Z' and 'N'.
      
      NOTE 1: This is a result of the undocumented feature: the LOAD DATA INFILE
      recognises 2-byte input sequences like \n, \t, \r and \Z in addition
      to documented 2-byte sequences: \0 and \N. This feature should be
      documented (here backspace character is a default ESCAPED BY character,
      in the real-life example it may be any ESCAPED BY character).
      
      NOTE 2, changed behaviour:
      Now the `SELECT INTO OUTFILE' statement with the `FIELDS ENCLOSED BY'
      clause followed by one of: 'n', 't', 'r', 'b', '0', 'Z' or 'N' characters
      encodes this special character itself by doubling it ('r' --> 'rr'),
      not by prepending it with an escape character.
      dbe4fb94