An error occurred fetching the project authors.
  1. 22 May, 2006 1 commit
    • andrey@lmy004.'s avatar
      fix for bug #17619 Scheduler race conditions · b429d73d
      andrey@lmy004. authored
      - Scheduler is either initialized at server start or never.
        Starting & stopping is now suspending & resuming.
      - The scheduler has clear OO interface
      - Now all calls to the scheduler are synchronous
      - GLOBAL event_scheduler uses thd::sys_var_tmp (see set_var.cc)
      - External API is encapsulated into class Events
      - Includes fixes for all comments of Kostja's review of 19.05.2005
      
      Starting to merge into 5.1-release (5.1.10) and push
      b429d73d
  2. 12 May, 2006 2 commits
  3. 11 May, 2006 1 commit
  4. 10 May, 2006 2 commits
  5. 08 May, 2006 1 commit
  6. 04 May, 2006 1 commit
    • tnurnberg@mysql.com's avatar
      Bug#19025 4.1 mysqldump doesn't correctly dump "auto_increment = [int]" · 5becb110
      tnurnberg@mysql.com authored
      mysqldump / SHOW CREATE TABLE will show the NEXT available value for
      the PK, rather than the *first* one that was available (that named in
      the original CREATE TABLE ... AUTO_INCREMENT = ... statement).
      
      This should produce correct and robust behaviour for the obvious use
      cases -- when no data were inserted, then we'll produce a statement
      featuring the same value the original CREATE TABLE had; if we dump
      with values, INSERTing the values on the target machine should set the
      correct next_ID anyway (and if not, we'll still have our AUTO_INCREMENT =
      ... to do that). Lastly, just the CREATE statement (with no data) for
      a table that saw inserts would still result in a table that new values
      could safely be inserted to).
      
      There seems to be no robust way however to see whether the next_ID
      field is > 1 because it was set to something else with CREATE TABLE
      ... AUTO_INCREMENT = ..., or because there is an AUTO_INCREMENT column
      in  the table (but no initial value was set with AUTO_INCREMENT = ...)
      and then one or more rows were INSERTed, counting up next_ID. This
      means that in both cases, we'll generate an AUTO_INCREMENT =
      ... clause in SHOW CREATE TABLE / mysqldump.  As we also show info on,
      say, charsets even if the user did not explicitly give that info in
      their own CREATE TABLE, this shouldn't be an issue.
      
      As per above, the next_ID will be affected by any INSERTs that have
      taken place, though.  This /should/ result in correct and robust
      behaviour, but it may look non-intuitive to some users if they CREATE
      TABLE ... AUTO_INCREMENT = 1000 and later (after some INSERTs) have
      SHOW CREATE TABLE give them a different value (say, CREATE TABLE
      ... AUTO_INCREMENT = 1006), so the docs should possibly feature a
      caveat to that effect.
      
      It's not very intuitive the way it works now (with the fix), but it's
      *correct*.  We're not storing the original value anyway, if we wanted
      that, we'd have to change on-disk representation?
      
      If we do dump/load cycles with empty DBs, nothing will change.  This
      changeset includes an additional test case that proves that tables
      with rows will create the same next_ID for AUTO_INCREMENT = ... across
      dump/restore cycles.
      
      Confirmed by support as likely solution for client's problem.
      5becb110
  7. 03 May, 2006 2 commits
  8. 02 May, 2006 2 commits
  9. 30 Apr, 2006 2 commits
  10. 13 Apr, 2006 1 commit
  11. 10 Apr, 2006 1 commit
  12. 07 Apr, 2006 1 commit
  13. 01 Apr, 2006 1 commit
  14. 31 Mar, 2006 1 commit
  15. 29 Mar, 2006 1 commit
    • monty@mysql.com's avatar
      Fixed compiler and valgrind warnings · 1994ed49
      monty@mysql.com authored
      Added missing DBUG_xxx_RETURN statements
      Fixed some usage of not initialized variables (as found by valgrind)
      Ensure that we don't remove locked tables used as name locks from open table cache until unlock_table_names() are called.
      This was fixed by having drop_locked_name() returning any table used as a name lock so that we can free it in unlock_table_names()
      This will allow Tomas to continue with his work to use namelocks to syncronize things.
      
      Note: valgrind still produces a lot of warnings about using not initialized code and shows memory loss errors when running the ndb tests
      1994ed49
  16. 20 Mar, 2006 2 commits
    • gluh@eagle.intranet.mysql.r18.ru's avatar
      Fix for bug#18224 VIEW on information_schema crashes the server · f78ae59f
      gluh@eagle.intranet.mysql.r18.ru authored
        additional check for subselect
      f78ae59f
    • gluh@eagle.intranet.mysql.r18.ru's avatar
      Fix for bug #18113 "SELECT * FROM information_schema.xxx crashes server" · a184a00e
      gluh@eagle.intranet.mysql.r18.ru authored
      Crash happened when one selected data from one of INFORMATION_SCHEMA
      tables and in order to build its contents server had to open view which
      used stored function and table or view on which one had not global or
      database-level privileges (e.g. had only table-level or had no
      privileges at all).
      
      The crash was caused by usage of check_grant() function, which assumes
      that either number of tables to be inspected by it is limited explicitly
      or table list used and thd->lex->query_tables_own_last value correspond
      to each other (the latter should be either 0 or point to next_global
      member of one of elements of this table list), in conditions when
      above assumptions were not true. This fix just explicitly limits
      number of tables to be inspected. Other negative effects which are
      caused by the fact that thd->lex->query_tables_own_last might not
      be set properly during processing of I_S tables are less disastrous
      and will be reported and fixed separetely.
      a184a00e
  17. 10 Mar, 2006 1 commit
  18. 09 Mar, 2006 2 commits
  19. 07 Mar, 2006 1 commit
  20. 28 Feb, 2006 2 commits
  21. 27 Feb, 2006 1 commit
  22. 25 Feb, 2006 1 commit
    • guilhem@mysql.com's avatar
      WL#2977 and WL#2712 global and session-level variable to set the binlog format (row/statement), · 00717495
      guilhem@mysql.com authored
      and new binlog format called "mixed" (which is statement-based except if only row-based is correct,
      in this cset it means if UDF or UUID is used; more cases could be added in later 5.1 release):
      SET GLOBAL|SESSION BINLOG_FORMAT=row|statement|mixed|default;
      the global default is statement unless cluster is enabled (then it's row) as in 5.1-alpha.
      It's not possible to use SET on this variable if a session is currently in row-based mode and has open temporary tables (because CREATE
      TEMPORARY TABLE was not binlogged so temp table is not known on slave),  or if NDB is enabled (because
      NDB does not support such change on-the-fly, though it will later), of if in a stored function (see below).
      The added tests test the possibility or impossibility to SET, their effects, and the mixed mode,
      including in prepared statements and in stored procedures and functions.
      Caveats:
      a) The mixed mode will not work for stored functions: in mixed mode, a stored function will
      always be binlogged as one call and in a statement-based way (e.g. INSERT VALUES(myfunc()) or SELECT myfunc()).
      b) for the same reason, changing the thread's binlog format inside a stored function is
      refused with an error message.
      c) the same problems apply to triggers; implementing b) for triggers will be done later (will ask
      Dmitri).
      Additionally, as the binlog format is now changeable by each user for his session, I remove the implication
      which was done at startup, where row-based automatically set log-bin-trust-routine-creators to 1
      (not possible anymore as a user can now switch to stmt-based and do nasty things again), and automatically
      set --innodb-locks-unsafe-for-binlog to 1 (was anyway theoretically incorrect as it disabled
      phantom protection).
      Plus fixes for compiler warnings.
      00717495
  23. 24 Feb, 2006 1 commit
  24. 22 Feb, 2006 1 commit
  25. 21 Feb, 2006 1 commit
  26. 20 Feb, 2006 2 commits
  27. 16 Feb, 2006 3 commits
  28. 14 Feb, 2006 2 commits
    • andrey@lmy004.'s avatar
      - final fixes for bug#16431 (Events: An event which alters itself disappears) · 815927e5
      andrey@lmy004. authored
      - fix for bug#16423 (Events: SHOW CREATE EVENT doesn't work)
      - this Changeset commits makes CREATE/UPDATE/DELETE EVENT real DDL statements
        by committing the currently open transaction before they are executed.
      - this Changeset also fixes a trailing space problem since the very early days
        of the internal cron
      - adds sophisticated checking of whether mysql.event was tampered accidentally
        or with purpose by an user.
      - adds a lot of inline function documentation - documents everything left
        uncodumented
      - INTERVAL_XXXX to XXX in I_S.EVENTS.INTERVAL_FIELD
      
      WL#1034 (Internal CRON)
      815927e5
    • gluh@eagle.intranet.mysql.r18.ru's avatar
      Bug#16591 Partitions: crash using information_schema.partitions · c42a608d
      gluh@eagle.intranet.mysql.r18.ru authored
      Bug#16695 Reading I_S.PARTITIONS with pre-5.1.6 partitioned tables crashes server
       issue a warning in case of error during table opening
      c42a608d