An error occurred fetching the project authors.
  1. 23 Dec, 2006 1 commit
  2. 21 Dec, 2006 1 commit
  3. 19 Dec, 2006 2 commits
  4. 30 Nov, 2006 2 commits
    • monty@mysql.com/narttu.mysql.fi's avatar
      Fixed portability issue in my_thr_init.c (was added in my last push) · 3d409560
      monty@mysql.com/narttu.mysql.fi authored
      Fixed compiler warnings (detected by VC++):
      - Removed not used variables
      - Added casts
      - Fixed wrong assignments to bool
      - Fixed wrong calls with bool arguments
      - Added missing argument to store(longlong), which caused wrong store method to be called.
      3d409560
    • monty@mysql.com/narttu.mysql.fi's avatar
      Fixed compiler warnings (Mostly VC++): · 3a35c300
      monty@mysql.com/narttu.mysql.fi authored
      - Removed not used variables
      - Changed some ulong parameters/variables to ulonglong (possible serious bug)
      - Added casts to get rid of safe assignment from longlong to long (and similar)
      - Added casts to function parameters
      - Fixed signed/unsigned compares
      - Added some constructores to structures
      - Removed some not portable constructs
      
      Better fix for bug Bug #21428 "skipped 9 bytes from file: socket (3)" on "mysqladmin shutdown"
      (Added new parameter to net_clear() to define when we want the communication buffer to be emptied)
      3a35c300
  5. 27 Nov, 2006 1 commit
  6. 26 Nov, 2006 1 commit
    • monty@mysql.com/nosik.monty.fi's avatar
      Fixed a LOT of compiler warnings · fa81a82e
      monty@mysql.com/nosik.monty.fi authored
      Added missing DBUG_RETURN statements (in mysqldump.c)
      Added missing enums
      Fixed a lot of wrong DBUG_PRINT() statements, some of which could cause crashes
      Removed usage of %lld and %p in printf strings as these are not portable or produces different results on different systems.
      fa81a82e
  7. 21 Nov, 2006 2 commits
    • kroki/tomash@moonlight.intranet's avatar
      BUG#23159: prepared_stmt_count should be status variable · 0d588f88
      kroki/tomash@moonlight.intranet authored
      Make Prepared_stmt_count a global status variable, accessible via
      SHOW STATUS LIKE 'Prepared_stmt_count';.  Documentation should be
      updated.
      0d588f88
    • malff/marcsql@weblab.(none)'s avatar
      WL#3602 (SET GLOBAL READONLY) · 070f5ad4
      malff/marcsql@weblab.(none) authored
      Bug#11733 (COMMITs should not happen if read-only is set)
      Bug#22009 (Can write to a read-only server under some circumstances)
      
      See the work log for details
      
      The change consist of
      a) acquiring the global read lock in SET GLOBAL READONLY
      b) honoring opt_readonly in ha_commit_trans(),
      c) honoring opt_readonly in mysql_lock_tables().
      
      a) takes care of the server stability,
      b) makes the transactional tables safe (Bug 11733)
      c) makes the non transactional tables safe (Bug 22009)
      070f5ad4
  8. 20 Nov, 2006 1 commit
  9. 11 Nov, 2006 1 commit
  10. 05 Nov, 2006 1 commit
  11. 30 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. 04 Oct, 2006 1 commit
  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. 29 Sep, 2006 1 commit
  17. 15 Sep, 2006 1 commit
  18. 01 Sep, 2006 1 commit
    • andrey@example.com's avatar
      WL#3337 (Event scheduler new architecture) · ca39997c
      andrey@example.com authored
      This is a post-review patch.
      
      Fixes the typelib implementation, available only in 5.1.11.
      
      --event-scheduler cmdline : DISABLED | ON | OFF | 0 | 1
      DISABLED - makes the scheduler unavailable during the server run
      (ON|1)-  When the server is started the scheduler will be started. It can
               be stopped and restarted by setting appropriate values to
               GLOBAL event_scheduler
      (OFF|0)- When the server is started, the scheduler won't be started. It
               can be started and again stopped by setting appropriate values to
               GLOBAL event_scheduler. _DEFAULT_ value
      
      The GLOBAL variable event_scheduler can have the following values:
      OFF | ON | 0 | 1
      DISABLED is not possible and every attempt will end with an error that
      it's not a valid value for the variable.
      OFF | 0 - This is the pre-5.1.11 behavior - The scheduler stops, if not
                already stopped, and can be started again  by setting
                the value of the variable to ON|1.
      ON | 1  - This is the pre-5.1.11 behavior - The scheduler starts, if not
                already started, and can be stopped again by setting the value
                of the variable to OFF|0.
      ca39997c
  19. 22 Aug, 2006 1 commit
    • evgen@sunlight.local's avatar
      Fixed bug#16861: User defined variable can have a wrong value if a tmp table was · f17a536e
      evgen@sunlight.local authored
      used.
      
      Sorting by RAND() uses a temporary table in order to get a correct results.
      User defined variable was set during filling the temporary table and later
      on it is substituted for its value from the temporary table. Due to this
      it contains the last value stored in the temporary table.
      
      Now if the result_field is set for the Item_func_set_user_var object it 
      updates variable from the result_field value when being sent to a client.
      
      The Item_func_set_user_var::check() now accepts a use_result_field
      parameter. Depending on its value the result_field or the args[0] is used
      to get current value.
      f17a536e
  20. 20 Aug, 2006 1 commit
  21. 17 Aug, 2006 2 commits
  22. 14 Aug, 2006 1 commit
  23. 10 Aug, 2006 1 commit
  24. 29 Jul, 2006 1 commit
  25. 21 Jul, 2006 1 commit
  26. 14 Jul, 2006 1 commit
  27. 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
  28. 07 Jul, 2006 1 commit
  29. 05 Jul, 2006 1 commit
    • andrey@lmy004.'s avatar
      WL#3337 (Event scheduler new architecture) · 3b840ade
      andrey@lmy004. authored
      Cleaned up the code a bit. Fixed few leaks.
      This code still does not load events on server startup
      from disk. The problem is that there is a need for a THD instance, which
      does not exist during server boot. This will be solved soon.
      Still Event_timed is used both for the memory queue and for exectution.
      This will be changed according to WL#3337 probably in the next commit.
      3b840ade
  30. 04 Jul, 2006 2 commits
    • andrey@lmy004.'s avatar
      WL #3337 (Event scheduler new architecture) · 2bdd872e
      andrey@lmy004. authored
      Cut Nr. 8.
      
      All tests pass.
      
      Separated Event_scheduler into Event_queue and Event_scheduler.
      Added new Event_scheduler_ng which is the new scheduler and is used
      system-wide. Will be moved to the event_scheduler.cc in the future.
      Using Event_timed in Event_queue as well as cloned during execution.
      Next step is to have Event_worker_data which will be used during execution
      and will take ::compile()/::execute() out of Event_timed.
      2bdd872e
    • bar@mysql.com's avatar
      WL#2928 Date Translation NRE · 38555201
      bar@mysql.com authored
      (implemented by by Josh Chamas)
      38555201
  31. 28 Jun, 2006 1 commit
  32. 27 Jun, 2006 2 commits
  33. 22 Jun, 2006 1 commit