An error occurred fetching the project authors.
  1. 10 Jan, 2007 1 commit
    • cbell/Chuck@suse.vabb.com's avatar
      BUG#22645 - LC_TIME_NAMES: Statement not replicated · 20036a42
      cbell/Chuck@suse.vabb.com authored
      This patch is an additional code change to the get_str_len_and_pointer 
      method in log_events.cc. This change is necessary to correct a problem
      encountered on 64-bit SUSE where the auto_increment_* variables were
      being overwritten. The change corrects a cast mismatch which caused
      the problem.
      20036a42
  2. 21 Dec, 2006 1 commit
    • mats@romeo.(none)'s avatar
      BUG#22864 (Rollback following CREATE... SELECT discards 'CREATE TABLE' · be9ffb12
      mats@romeo.(none) authored
      from log):
      When row-based logging is used, the CREATE-SELECT is written as two
      parts: as a CREATE TABLE statement and as the rows for the table. For
      both transactional and non-transactional tables, the CREATE TABLE
      statement was written to the transaction cache, as were the rows, and
      on statement end, the entire transaction cache was written to the binary
      log if the table was non-transactional. For transactional tables, the
      events were kept in the transaction cache until end of transaction (or
      statement that were not part of a transaction).
      
      For the case when AUTOCOMMIT=0 and we are creating a transactional table
      using a create select, we would then keep the CREATE TABLE statement and
      the rows for the CREATE-SELECT, while executing the following statements.
      On a rollback, the transaction cache would then be cleared, which would
      also remove the CREATE TABLE statement. Hence no table would be created
      on the slave, while there is an empty table on the master.
      
      This relates to BUG#22865 where the table being created exists on the
      master, but not on the slave during insertion of rows into the newly
      created table. This occurs since the CREATE TABLE statement were still
      in the transaction cache until the statement finished executing, and
      possibly longer if the table was transactional.
      
      This patch changes the behaviour of the CREATE-SELECT statement by
      adding an implicit commit at the end of the statement when creating
      non-temporary tables. Hence, non-temporary tables will be written to the
      binary log on completion, and in the even of AUTOCOMMIT=0, a new
      transaction will be started. Temporary tables do not commit an ongoing
      transaction: neither as a pre- not a post-commit.
      
      The events for both transactional and non-transactional tables are
      saved in the transaction cache, and written to the binary log at end
      of the statement.
      be9ffb12
  3. 07 Dec, 2006 2 commits
  4. 30 Nov, 2006 1 commit
    • 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. 28 Nov, 2006 1 commit
  6. 14 Nov, 2006 1 commit
  7. 12 Nov, 2006 1 commit
  8. 06 Oct, 2006 1 commit
    • mats@romeo.(none)'s avatar
      BUG#19459 (BINLOG RBR command does not lock tables correctly causing · e762328b
      mats@romeo.(none) authored
      crash for, e.g., NDB):
      
      Before, mysqlbinlog printed table map events as a separate statement, so
      when executing the event, the opened table was subsequently closed
      when the statement ended. Instead, the row-based events that make up
      a statement are now printed as *one* BINLOG statement, which means
      that the table maps and the following *_rows_log_event events are
      executed fully before the statement ends.
      
      Changing implementation of BINLOG statement to be able to read the 
      emitted format, which now consists of several chunks of BASE64-encoded
      data.
      e762328b
  9. 11 Sep, 2006 1 commit
  10. 12 Jun, 2006 1 commit
  11. 31 May, 2006 1 commit
  12. 17 May, 2006 1 commit
    • guilhem@mysql.com's avatar
      Removing the binlog-show-xid option as it was only a temporary solution until... · c1b11edf
      guilhem@mysql.com authored
      Removing the binlog-show-xid option as it was only a temporary solution until we have replace-regex which we have now.
      That option was used to suppress the XID from the output of SHOW BINLOG EVENTS (to create a repeatable testsuite),
      was available only in debug builds, and was explicitely marked as "may be removed in future versions" in mysqld --help.
      Idea of the removal approved by the replication team.
      c1b11edf
  13. 05 May, 2006 1 commit
  14. 03 May, 2006 1 commit
  15. 16 Apr, 2006 1 commit
  16. 08 Mar, 2006 1 commit
  17. 25 Feb, 2006 2 commits
    • 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
    • monty@mysql.com's avatar
      Fixed compiler warnings from gcc 4.0.2: · 54274976
      monty@mysql.com authored
      - Added empty constructors and virtual destructors to many classes and structs
      - Removed some usage of the offsetof() macro to instead use C++ class pointers
      54274976
  18. 24 Feb, 2006 1 commit
  19. 16 Feb, 2006 1 commit
  20. 20 Jan, 2006 1 commit
  21. 13 Jan, 2006 1 commit
  22. 10 Jan, 2006 1 commit
  23. 09 Jan, 2006 3 commits
  24. 30 Dec, 2005 1 commit
  25. 22 Dec, 2005 1 commit
  26. 27 Oct, 2005 1 commit
  27. 24 Oct, 2005 2 commits
  28. 19 Oct, 2005 1 commit
  29. 12 Oct, 2005 3 commits
  30. 29 Sep, 2005 2 commits
  31. 02 Sep, 2005 1 commit
    • konstantin@mysql.com's avatar
      Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures". · 38486e83
      konstantin@mysql.com authored
      The idea of the patch is to separate statement processing logic,
      such as parsing, validation of the parsed tree, execution and cleanup, 
      from global query processing logic, such as logging, resetting
      priorities of a thread, resetting stored procedure cache, resetting
      thread count of errors and warnings.
      This makes PREPARE and EXECUTE behave similarly to the rest of SQL
      statements and allows their use in stored procedures.
      This patch contains a change in behaviour:
      until recently for each SQL prepared statement command, 2 queries
      were written to the general log, e.g.
      [Query]   prepare stmt from @stmt_text;
      [Prepare] select * from t1 <-- contents of @stmt_text
      The chagne was necessary to prevent [Prepare] commands from being written
      to the general log when executing a stored procedure with Dynamic SQL.
      We should consider whether the old behavior is preferrable and probably
      restore it.
      This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
      in Dynamic SQL reported before it was disabled).
      38486e83
  32. 19 Aug, 2005 1 commit