An error occurred fetching the project authors.
  1. 06 Jul, 2006 2 commits
    • guilhem@gbichot3.local's avatar
      Testcase for BUG#20633 "INSERT DELAYED RAND() or @user_var does not replicate · 6ba4d22c
      guilhem@gbichot3.local authored
      statement-based" (bugfix was committed today):
      we verify that now it works in mixed mode. And a comment.
      6ba4d22c
    • guilhem@gbichot3.local's avatar
      Fix for BUG#20649 "mixed replication mode does not work with INSERT DELAYED". · a5f184d5
      guilhem@gbichot3.local authored
      The bug was that if the server was running in mixed binlogging mode,
      and an INSERT DELAYED used some needing-row-based components like UUID(),
      the server didn't binlog this row-based but statement-based, which
      thus failed to insert correct data on the slave.
      This changeset implements that when a delayed_insert thread is created,
      if the server's global binlog mode is "mixed", that thread will use row-based.
      This also fixes BUG#20633 "INSERT DELAYED RAND() or @user_var does not
      replicate statement-based": we don't fix it in statement-based mode (would
      require bookeeping of rand seeds and user variables used by each row),
      but at least it will now work in mixed mode (as row-based will be used).
      We re-enable rpl_switch_stm_row_mixed.test (so BUG#18590
      which was about re-enabling this test, will be closed) to test the fixes.
      Between when it was disabled and now, some good changes to row-based
      binlogging (no generation of table map events for non-changed tables)
      induce changes in the test's result file.
      a5f184d5
  2. 13 Mar, 2006 1 commit
  3. 09 Mar, 2006 1 commit
  4. 26 Feb, 2006 1 commit
  5. 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