An error occurred fetching the project authors.
  1. 27 Oct, 2005 1 commit
  2. 24 Oct, 2005 2 commits
  3. 19 Oct, 2005 1 commit
  4. 12 Oct, 2005 3 commits
  5. 29 Sep, 2005 2 commits
  6. 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
  7. 19 Aug, 2005 1 commit
  8. 06 Aug, 2005 1 commit
  9. 01 Jul, 2005 1 commit
  10. 26 May, 2005 1 commit
  11. 05 May, 2005 1 commit
    • gbichot@quadita2.mysql.com's avatar
      Approximative fixes for BUG#2610,2611,9100 i.e. WL#2146... · b72ae4fe
      gbichot@quadita2.mysql.com authored
        Approximative fixes for BUG#2610,2611,9100 i.e. WL#2146 binlogging/replication of routines (stored procs and functions).
        Approximative, because it's using our binlogging way (what we call "query"-level) and this is not as good as record-level binlog (5.1) would be. It imposes several
        limitations to routines, and has caveats (which I'll document, and for which the server will try to issue errors but that is not always possible).
        Reason I don't propagate caller info to the binlog as planned is that on master and slave
        users may be different; even with that some caveats would remain.
      b72ae4fe
  12. 30 Mar, 2005 2 commits
  13. 25 Mar, 2005 1 commit
    • gbichot@quadita2.mysql.com's avatar
      WWe now store the catalog in Query_log_event in binlog WITHOUT its end zero. · ead47f47
      gbichot@quadita2.mysql.com authored
      This saves one byte per Query_log_event on disk compared to 5.0.[0..3]. Compatibility problems with 5.0.x where x<4
      are explained in the comments in log_event.cc. Putting back s/my_open(O_TRUNC)/(my_delete+my_create) change which had
      been wiped away by somebody doing a wrong 4.1->5.0 merge (which happened just
      before 5.0.3 :( ). Applying it to new events for LOAD DATA INFILE.
      If slave fails in Execute_load_query_log_event::exec_event(),
      don't delete the file (so that it's re-usable at next START SLAVE).
      And (youpi!) fix for BUG#3247 "a partially completed LOAD DATA INFILE is not
      executed at all on the slave" (storing an Execute_load_query_log_event
      to binlog, with its error code, instead of Delete_file_log_event).
      ead47f47
  14. 21 Mar, 2005 1 commit
  15. 16 Mar, 2005 1 commit
    • dlenev@brandersnatch.localdomain's avatar
      WL#874 "Extended LOAD DATA". · f1691140
      dlenev@brandersnatch.localdomain authored
      Now one can use user variables as target for data loaded from file
      (besides table's columns). Also LOAD DATA got new SET-clause in which
      one can specify values for table columns as expressions.
      
      For example the following is possible:
      LOAD DATA INFILE 'words.dat' INTO TABLE t1 (a, @b) SET c = @b + 1;
      
      This patch also implements new way of replicating LOAD DATA.
      Now we do it similarly to other queries.
      We store LOAD DATA query in new Execute_load_query event
      (which is last in the sequence of events representing LOAD DATA).
      When we are executing this event we simply rewrite part of query which
      holds name of file (we use name of temporary file) and then execute it
      as usual query. In the beggining of this sequence we use Begin_load_query
      event which is almost identical to Append_file event
      f1691140
  16. 23 Feb, 2005 1 commit
  17. 17 Feb, 2005 1 commit
  18. 09 Feb, 2005 1 commit
  19. 03 Feb, 2005 1 commit
    • guilhem@mysql.com's avatar
      WL#1062 "log charset info into all Query_log_event": · ed1696f6
      guilhem@mysql.com authored
      we store 7 bytes (1 + 2*3) in every Query_log_event.
      In the future if users want binlog optimized for small size and less safe,
      we could add --binlog-no-charset (and binlog-no-sql-mode etc): charset info
      is something by design optional (even if for now we don't offer possibility to disable it):
      it's not a binlog format change.
      We try to reduce the number of get_charset() calls in the slave SQL thread to a minimum
      by caching the charset read from the previous event (which will often be equal to the one of the current event).
      We don't use SET ONE_SHOT for charset-aware repl (we still do for timezones, will be fixed later).
      No more errors if one changes the global value of charset vars on master or slave
      (as we log charset info in all Query_log_event).
      Not fixing Load_log_event as it will be rewritten soon by Dmitri.
      Testing how mysqlbinlog behaves in rpl_charset.test.
      mysqlbinlog needs to know where charset file is (to be able to convert a charset number found
      in binlog (e.g. in User_var_log_event) to a charset name); mysql-test-run needs to pass
      the correct value for this option to mysqlbinlog.
      Many result udpates (adding charset info into every event shifts log_pos in SHOW BINLOG EVENTS).
      Roughly the same job is to be done for timezones :)
      ed1696f6
  20. 27 Jan, 2005 1 commit
  21. 16 Jan, 2005 1 commit
  22. 31 Dec, 2004 1 commit
  23. 03 Dec, 2004 1 commit
    • mats@mysql.com's avatar
      Bug#6391 (binlog-do-db rules ignored) · 2bbdf240
      mats@mysql.com authored
        CREATE DATABASE statement used the current database instead of the
        database created when checking conditions for replication.
        CREATE/DROP/ALTER DATABASE statements are now replicated based on
        the manipulated database.
      2bbdf240
  24. 15 Nov, 2004 1 commit
    • lars@mysql.com's avatar
      BUG#6353 V2: · b7cfe5ec
      lars@mysql.com authored
      Replication using replicate-rewrite-db did not work for LOAD DATA INFILE.
      Now is does.  There was one place in the code that used current database 
      instead of the rewrite database.
      b7cfe5ec
  25. 14 Oct, 2004 1 commit
  26. 15 Sep, 2004 1 commit
    • monty@mishka.local's avatar
      Added options --auto-increment-increment and --auto-increment-offset. · 91ff64e1
      monty@mishka.local authored
      This allows one to setup a master <-> master replication with non conflicting auto-increment series.
      Cleaned up binary log code to make it easyer to add new state variables.
      Added simpler 'upper level' logic for artificial events (events that should not cause cleanups on slave).
      Simplified binary log handling.
      Changed how auto_increment works together with to SET INSERT_ID=# to make it more predictable: Now the inserted rows in a multi-row statement are set independent of the existing rows in the table. (Before only InnoDB did this correctly)
      
      91ff64e1
  27. 26 Jul, 2004 1 commit
  28. 20 Jul, 2004 1 commit
  29. 13 Feb, 2004 1 commit
  30. 06 Feb, 2004 1 commit
  31. 21 Dec, 2003 1 commit
  32. 18 Dec, 2003 1 commit
    • guilhem@gbichot2's avatar
      This will be pushed only after I fix the testsuite. · 66a32e89
      guilhem@gbichot2 authored
      This is the main commit for Worklog tasks:
       * A more dynamic binlog format which allows small changes (1064)
       * Log session variables in Query_log_event (1063)
      Below 5.0 means 5.0.0.
      MySQL 5.0 is able to replicate FOREIGN_KEY_CHECKS, UNIQUE_KEY_CHECKS (for speed),
      SQL_AUTO_IS_NULL, SQL_MODE. Not charsets (WL#1062), not some vars (I can only think
      of SQL_SELECT_LIMIT, which deserves a special treatment). Note that this
      works for queries, except LOAD DATA INFILE (for this it would have to wait
      for Dmitri's push of WL#874, which in turns waits for the present push, so...
      the deadlock must be broken!). Note that when Dmitri pushes WL#874 in 5.0.1,
      5.0.0 won't be able to replicate a LOAD DATA INFILE from 5.0.1.
      Apart from that, the new binlog format is designed so that it can tolerate
      a little variation in the events (so that a 5.0.0 slave could replicate a
      5.0.1 master, except for LOAD DATA INFILE unfortunately); that is, when I
      later add replication of charsets it should break nothing. And when I later
      add a UID to every event, it should break nothing.
      The main change brought by this patch is a new type of event, Format_description_log_event,
      which describes some lengthes in other event types. This event is needed for
      the master/slave/mysqlbinlog to understand a 5.0 log. Thanks to this event,
      we can later add more bytes to the header of every event without breaking compatibility.
      Inside Query_log_event, we have some additional dynamic format, as every Query_log_event
      can have a different number of status variables, stored as pairs (code, value); that's
      how SQL_MODE and session variables and catalog are stored. Like this, we can later
      add count of affected rows, charsets... and we can have options --don't-log-count-affected-rows
      if we want.
      MySQL 5.0 is able to run on 4.x relay logs, 4.x binlogs.
      Upgrading a 4.x master to 5.0 is ok (no need to delete binlogs),
      upgrading a 4.x slave to 5.0 is ok (no need to delete relay logs);
      so both can be "hot" upgrades.
      Upgrading a 3.23 master to 5.0 requires as much as upgrading it to 4.0.
      3.23 and 4.x can't be slaves of 5.0.
      So downgrading from 5.0 to 4.x may be complicated.
      Log_event::log_pos is now the position of the end of the event, which is
      more useful than the position of the beginning. We take care about compatibility
      with <5.0 (in which log_pos is the beginning).
      I added a short test for replication of SQL_MODE and some other variables.
      TODO:
      - after committing this, merge the latest 5.0 into it
      - fix all tests
      - update the manual with upgrade notes.
      66a32e89
  33. 08 Dec, 2003 1 commit
    • guilhem@mysql.com's avatar
      Fix for BUG#2045 "Sending SIGHUP to mysqld crashes it if running with --log-bin". · dba12258
      guilhem@mysql.com authored
      The constructor of Rotate_log_event used when we are rotating our binlog or
      relay log, should not assume that there is a nonzero THD available.
      For example, when we are reacting to SIGHUP, the THD is 0.
      In fact we don't need to use the THD in this constructor;
      we can do like for Stop_log_event, and use the minimal Log_event
      constructor.
      If we were allowed to put Unix-specific commands in the testsuite,
      I'd add a test for this (<sigh>).
      dba12258
  34. 02 Dec, 2003 1 commit
    • guilhem@mysql.com's avatar
      There is no reason that Intvar_log_event's constructor calls Log_event::Log_event() · 7eda171f
      guilhem@mysql.com authored
      instead of Log_event::Log_event(THD*, ...) when the event is built in the master
      to be written in the binlog.
      Rand_log_event already used the good constructor, so there really is no reason
      for Intvar_log_event to be an exception.
      This fixes a test failure of last night (which appeared after I removed a useless
      e.server_id=thd->server_id in log.cc; in fact this line was not useless because
      it hid the bad constructor).
      Replication tests pass, with Valgrind too.
      7eda171f
  35. 29 Oct, 2003 1 commit
    • guilhem@mysql.com's avatar
      Fix for BUG#1686 · 59d0872a
      guilhem@mysql.com authored
      "If 2 master threads with same-name temp table, slave makes bad binlog"
      and (two birds with one stone) for
      BUG#1240 "slave of slave breaks when STOP SLAVE was issud on parent slave
      and temp tables".
      
      Here is the design change:
      in a slave running with --log-slave-updates, events are now logged with the
      thread id they had on the master. So no more id conflicts between master threads,
      but introduces id conflicts between one master thread and one normal 
      client thread connected to the slave. This is solved by storing the server id
      in the temp table's name.
      
      New test which requires mysql-test-run to be run with --manager,
      otherwise it will be skipped.
      
      Undoing a Monty's change (hum, a chill runs down my spine ;) which was
      "Cleanup temporary tables when slave ends" in ChangeSet 1.1572.1.1.
      59d0872a