An error occurred fetching the project authors.
  1. 31 Dec, 2006 1 commit
    • kent@mysql.com/kent-amd64.(none)'s avatar
      my_strtoll10-x86.s: · 6523aca7
      kent@mysql.com/kent-amd64.(none) authored
        Corrected spelling in copyright text
      Makefile.am:
        Don't update the files from BitKeeper
      Many files:
        Removed "MySQL Finland AB & TCX DataKonsult AB" from copyright header
        Adjusted year(s) in copyright header 
      Many files:
        Added GPL copyright text
      Removed files:
        Docs/Support/colspec-fix.pl
        Docs/Support/docbook-fixup.pl
        Docs/Support/docbook-prefix.pl
        Docs/Support/docbook-split
        Docs/Support/make-docbook
        Docs/Support/make-makefile
        Docs/Support/test-make-manual
        Docs/Support/test-make-manual-de
        Docs/Support/xwf
      6523aca7
  2. 23 Dec, 2006 1 commit
  3. 01 Dec, 2006 1 commit
  4. 28 Nov, 2006 1 commit
  5. 27 Nov, 2006 1 commit
  6. 20 Nov, 2006 1 commit
    • monty@mysql.com/nosik.monty.fi's avatar
      Remove compiler warnings · e8258798
      monty@mysql.com/nosik.monty.fi authored
      (Mostly in DBUG_PRINT() and unused arguments)
      Fixed bug in query cache when used with traceing (--with-debug)
      Fixed memory leak in mysqldump
      Removed warnings from mysqltest scripts (replaced -- with #)
      e8258798
  7. 01 Nov, 2006 2 commits
  8. 30 Oct, 2006 1 commit
  9. 27 Oct, 2006 1 commit
  10. 24 Oct, 2006 1 commit
  11. 16 Oct, 2006 1 commit
  12. 06 Oct, 2006 1 commit
    • kroki/tomash@moonlight.intranet's avatar
      BUG#21726: Incorrect result with multiple invocations of LAST_INSERT_ID. · ee0cebf9
      kroki/tomash@moonlight.intranet authored
      Note: bug#21726 does not directly apply to 4.1, as it doesn't have stored
      procedures.  However, 4.1 had some bugs that were fixed in 5.0 by the
      patch for bug#21726, and this patch is a backport of those fixes.
      Namely, in 4.1 it fixes:
      
        - LAST_INSERT_ID(expr) didn't return value of expr (4.1 specific).
      
        - LAST_INSERT_ID() could return the value generated by current
          statement if the call happens after the generation, like in
      
            CREATE TABLE t1 (i INT AUTO_INCREMENT PRIMARY KEY, j INT);
            INSERT INTO t1 VALUES (NULL, 0), (NULL, LAST_INSERT_ID());
      
        - Redundant binary log LAST_INSERT_ID_EVENTs could be generated.
      ee0cebf9
  13. 05 Oct, 2006 1 commit
    • mats@romeo.(none)'s avatar
      I had forgotten to delete an already disabled line of C++ code. · a4e0b4e6
      mats@romeo.(none) authored
      ---
      BUG#20265 (Replication of CREATE-SELECT does not work correctly):
      Fixing bug by making binary log handle statement transactions.
      The binary log transaction cache can now be truncated to remove 
      events inserted during this statement or transaction. Also, the
      binary log participate in XA transaction handling, although not
      as a full 2pc resource.
      a4e0b4e6
  14. 03 Oct, 2006 1 commit
    • kroki/tomash@moonlight.intranet's avatar
      Fix for the patch for bug#21726: Incorrect result with multiple · 8798b462
      kroki/tomash@moonlight.intranet authored
      invocations of LAST_INSERT_ID.
      
      Reding of LAST_INSERT_ID inside stored function wasn't noted by caller,
      and no LAST_INSERT_ID_EVENT was issued for binary log.
      
      The solution is to add THD::last_insert_id_used_bin_log, which is much
      like THD::last_insert_id_used, but is reset only for upper-level
      statements.  This new variable is used to issue LAST_INSERT_ID_EVENT.
      8798b462
  15. 02 Oct, 2006 1 commit
    • kroki/tomash@moonlight.intranet's avatar
      BUG#21726: Incorrect result with multiple invocations of LAST_INSERT_ID · 5ea8adfa
      kroki/tomash@moonlight.intranet authored
      Non-upper-level INSERTs (the ones in the body of stored procedure,
      stored function, or trigger) into a table that have AUTO_INCREMENT
      column didn't affected the result of LAST_INSERT_ID() on this level.
      
      The problem was introduced with the fix of bug 6880, which in turn was
      introduced with the fix of bug 3117, where current insert_id value was
      remembered on the first call to LAST_INSERT_ID() (bug 3117) and was
      returned from that function until it was reset before the next
      _upper-level_ statement (bug 6880).
      
      The fix for bug#21726 brings back the behaviour of version 4.0, and
      implements the following: remember insert_id value at the beginning
      of the statement or expression (which at that point equals to
      the first insert_id value generated by the previous statement), and
      return that remembered value from LAST_INSERT_ID() or @@LAST_INSERT_ID.
      
      Thus, the value returned by LAST_INSERT_ID() is not affected by values
      generated by current statement, nor by LAST_INSERT_ID(expr) calls in
      this statement.
      
      Version 5.1 does not have this bug (it was fixed by WL 3146).
      5ea8adfa
  16. 27 Sep, 2006 1 commit
  17. 13 Sep, 2006 3 commits
  18. 08 Sep, 2006 1 commit
  19. 07 Sep, 2006 1 commit
  20. 04 Sep, 2006 1 commit
  21. 17 Aug, 2006 1 commit
  22. 19 Jul, 2006 1 commit
    • kostja@bodhi.local's avatar
      A fix and a test case for Bug#21002 "Derived table not selecting from a · f22a4ce1
      kostja@bodhi.local authored
      "real" table fails in JOINs".
      
      This is a regression caused by the fix for Bug 18444. 
      This fix removed the assignment of empty_c_string to table->db performed 
      in add_table_to_list, as neither me nor anyone else knew what it was 
      there for. Now we know it and it's covered with tests: the only case 
      when a table database name can be empty is when the table is a derived 
      table. The fix puts the assignment back but makes it a bit more explicit.
      
      Additionally, finally drop sp.result.orig which was checked in by mistake. 
      f22a4ce1
  23. 13 Jul, 2006 3 commits
  24. 12 Jul, 2006 1 commit
  25. 10 Jul, 2006 2 commits
    • guilhem@gbichot3.local's avatar
      fixes after merge. Updates to test's results. · 1cc3c800
      guilhem@gbichot3.local authored
      We now reset the THD members related to auto_increment+binlog in
      MYSQL_LOG::write(). This is better than in THD::cleanup_after_query(),
      which was not able to distinguish between SELECT myfunc1(),myfunc2()
      and INSERT INTO t SELECT myfunc1(),myfunc2() from a binlogging point
      of view.
      Rows_log_event::exec_event() now calls lex_start() instead of
      mysql_init_query() because the latter now does too much (it resets
      the binlog format).
      1cc3c800
    • gkodinov/kgeorge@mysql.com/rakia.(none)'s avatar
      BUG#14553: NULL in WHERE resets LAST_INSERT_ID · 2c9f5cc7
      To make MySQL compatible with some ODBC applications, you can find
      the AUTO_INCREMENT value for the last inserted row with the following query:
       SELECT * FROM tbl_name WHERE auto_col IS NULL.
      This is done with a special code that replaces 'auto_col IS NULL' with
      'auto_col = LAST_INSERT_ID'.
      However this also resets the LAST_INSERT_ID to 0 as it uses it for a flag
      so as to ensure that only the first SELECT ... WHERE auto_col IS NULL
      after an INSERT has this special behaviour.
      In order to avoid resetting the LAST_INSERT_ID a special flag is introduced
      in the THD class. This flag is used to restrict the second and subsequent
      SELECTs instead of LAST_INSERT_ID.
      2c9f5cc7
  26. 09 Jul, 2006 2 commits
    • guilhem@gbichot3.local's avatar
      WL#3146 "less locking in auto_increment": · 0594e1b8
      guilhem@gbichot3.local authored
      this is a cleanup patch for our current auto_increment handling:
      new names for auto_increment variables in THD, new methods to manipulate them
      (see sql_class.h), some move into handler::, causing less backup/restore
      work when executing substatements. 
      This makes the logic hopefully clearer, less work is is needed in
      mysql_insert().
      By cleaning up, using different variables for different purposes (instead
      of one for 3 things...), we fix those bugs, which someone may want to fix
      in 5.0 too:
      BUG#20339 "stored procedure using LAST_INSERT_ID() does not replicate
      statement-based"
      BUG#20341 "stored function inserting into one auto_increment puts bad
      data in slave"
      BUG#19243 "wrong LAST_INSERT_ID() after ON DUPLICATE KEY UPDATE"
      (now if a row is updated, LAST_INSERT_ID() will return its id)
      and re-fixes:
      BUG#6880 "LAST_INSERT_ID() value changes during multi-row INSERT"
      (already fixed differently by Ramil in 4.1)
      Test of documented behaviour of mysql_insert_id() (there was no test).
      The behaviour changes introduced are:
      - LAST_INSERT_ID() now returns "the first autogenerated auto_increment value
      successfully inserted", instead of "the first autogenerated auto_increment
      value if any row was successfully inserted", see auto_increment.test.
      Same for mysql_insert_id(), see mysql_client_test.c.
      - LAST_INSERT_ID() returns the id of the updated row if ON DUPLICATE KEY
      UPDATE, see auto_increment.test. Same for mysql_insert_id(), see
      mysql_client_test.c.
      - LAST_INSERT_ID() does not change if no autogenerated value was successfully 
      inserted (it used to then be 0), see auto_increment.test.
      - if in INSERT SELECT no autogenerated value was successfully inserted,
      mysql_insert_id() now returns the id of the last inserted row (it already
      did this for INSERT VALUES), see mysql_client_test.c.
      - if INSERT SELECT uses LAST_INSERT_ID(X), mysql_insert_id() now returns X
      (it already did this for INSERT VALUES), see mysql_client_test.c.
      - NDB now behaves like other engines wrt SET INSERT_ID: with INSERT IGNORE,
      the id passed in SET INSERT_ID is re-used until a row succeeds; SET INSERT_ID
      influences not only the first row now.
      
      Additionally, when unlocking a table we check that the thread is not keeping
      a next_insert_id (as the table is unlocked that id is potentially out-of-date);
      forgetting about this next_insert_id is done in a new
      handler::ha_release_auto_increment().
      
      Finally we prepare for engines capable of reserving finite-length intervals
      of auto_increment values: we store such intervals in THD. The next step
      (to be done by the replication team in 5.1) is to read those intervals from
      THD and actually store them in the statement-based binary log. NDB
      will be a good engine to test that.
      0594e1b8
    • guilhem@gbichot3.local's avatar
      * Mixed replication mode * : · fdb0f85a
      guilhem@gbichot3.local authored
      1) Fix for BUG#19630 "stored function inserting into two auto_increment breaks
      statement-based binlog":
      a stored function inserting into two such tables may fail to replicate
      (inserting wrong data in the slave's copy of the second table) if the slave's
      second table had an internal auto_increment counter different from master's.
      Because the auto_increment value autogenerated by master for the 2nd table
      does not go into binlog, only the first does, so the slave lacks information.
      To fix this, if running in mixed binlogging mode, if the stored function or
      trigger plans to update two different tables both having auto_increment
      columns, we switch to row-based for the whole function.
      We don't have a simple solution for statement-based binlogging mode, there
      the bug remains and will be documented as a known problem.
      Re-enabling rpl_switch_stm_row_mixed.
      2) Fix for BUG#20630 "Mixed binlogging mode does not work with stored
      functions, triggers, views", which was a documented limitation (in mixed
      mode, we didn't detect that a stored function's execution needed row-based
      binlogging (due to some UUID() call for example); same for
      triggers, same for views (a view created from a SELECT UUID(), and doing
      INSERT INTO sometable SELECT theview; would not replicate row-based).
      This is implemented by, after parsing a routine's body, remembering in sp_head
      that this routine needs row-based binlogging. Then when this routine is used,
      the caller is marked to require row-based binlogging too.
      Same for views: when we parse a view and detect that its SELECT needs
      row-based binary logging, we mark the calling LEX as such.
      3) Fix for BUG#20499 "mixed mode with temporary table breaks binlog":
      a temporary table containing e.g. UUID has its changes not binlogged,
      so any query updating a permanent table with data from the temporary table
      will run wrongly on slave. Solution: in mixed mode we don't switch back
      from row-based to statement-based when there exists temporary tables.
      4) Attempt to test mysqlbinlog on a binlog generated by mysqlbinlog;
      impossible due to BUG#11312 and BUG#20329, but test is in place for when
      they are fixed.
      fdb0f85a
  27. 04 Jul, 2006 1 commit
  28. 28 Jun, 2006 1 commit
    • konstantin@mysql.com's avatar
      A fix for Bug#19022 "Memory bug when switching db during trigger execution". · 55d148c5
      konstantin@mysql.com authored
      No test case as the bug is in an existing test case (rpl_trigger.test
      when it is run under valgrind).
      The warning was caused by memory corruption in replication slave: thd->db
      was pointing at a stack address that was previously used by 
      sp_head::execute()::old_db. This happened because mysql_change_db
      behaved differently in replication slave and did not make a copy of the 
      argument to assign to thd->db. 
      The solution is to always free the old value of thd->db and allocate a new
      copy, regardless whether we're running in a replication slave or not.
      55d148c5
  29. 27 Jun, 2006 2 commits
  30. 26 Jun, 2006 1 commit
    • konstantin@mysql.com's avatar
      A fix and a test case for · 117b76a5
      konstantin@mysql.com authored
       Bug#19022 "Memory bug when switching db during trigger execution"
       Bug#17199 "Problem when view calls function from another database."
       Bug#18444 "Fully qualified stored function names don't work correctly in
                  SELECT statements"
      
       Documentation note: this patch introduces a change in behaviour of prepared
       statements.
      
       This patch adds a few new invariants with regard to how THD::db should
       be used. These invariants should be preserved in future:
      
        - one should never refer to THD::db by pointer and always make a deep copy
          (strmake, strdup)
        - one should never compare two databases by pointer, but use strncmp or
          my_strncasecmp
        - TABLE_LIST object table->db should be always initialized in the parser or
          by creator of the object.
      
          For prepared statements it means that if the current database is changed
          after a statement is prepared, the database that was current at prepare
          remains active. This also means that you can not prepare a statement that
          implicitly refers to the current database if the latter is not set.
          This is not documented, and therefore needs documentation. This is NOT a
          change in behavior for almost all SQL statements except:
           - ALTER TABLE t1 RENAME t2 
           - OPTIMIZE TABLE t1
           - ANALYZE TABLE t1
           - TRUNCATE TABLE t1 --
           until this patch t1 or t2 could be evaluated at the first execution of
           prepared statement. 
      
           CURRENT_DATABASE() still works OK and is evaluated at every execution
           of prepared statement.
      
           Note, that in stored routines this is not an issue as the default
           database is the database of the stored procedure and "use" statement
           is prohibited in stored routines.
      
        This patch makes obsolete the use of check_db_used (it was never used in the
        old code too) and all other places that check for table->db and assign it
        from THD::db if it's NULL, except the parser.
      
       How this patch was created: THD::{db,db_length} were replaced with a
       LEX_STRING, THD::db. All the places that refer to THD::{db,db_length} were
       manually checked and:
        - if the place uses thd->db by pointer, it was fixed to make a deep copy
        - if a place compared two db pointers, it was fixed to compare them by value
          (via strcmp/my_strcasecmp, whatever was approproate)
       Then this intermediate patch was used to write a smaller patch that does the
       same thing but without a rename.
      
       TODO in 5.1:
         - remove check_db_used
         - deploy THD::set_db in mysql_change_db
      
       See also comments to individual files.
      117b76a5
  31. 23 Jun, 2006 1 commit
  32. 22 Jun, 2006 1 commit