An error occurred fetching the project authors.
  1. 24 Feb, 2009 1 commit
  2. 20 Feb, 2009 1 commit
    • Andrei Elkin's avatar
      Bug #37313 BINLOG Contains Incorrect server id · c02752a0
      Andrei Elkin authored
        
      Signed integer format specifier forced to print the binlog header with server_id
      negative if the unsigned value sets the sign-bit ON.
        
      Fixed with correcting the specifier to correspond to typeof(server_id) == ulong.
      c02752a0
  3. 19 Feb, 2009 1 commit
  4. 16 May, 2008 1 commit
  5. 15 May, 2008 1 commit
    • cmiller@zippy.cornsilk.net's avatar
      Bug#36570: Parse error of CREATE PROCEDURE stmt with comments on \ · 573828aa
      cmiller@zippy.cornsilk.net authored
      	slave
      
      The stored-routine code took the contents of the (lowest) parser
      and copied it directly to the binlog, which causes problems if there
      is a special case of interpretation at the parser level -- which 
      there is, in the "/*!VER */" comments.  The trailing "*/" caused
      errors on the slave, naturally.
      
      Now, since by that point we have /properly/ created parse-tree (as 
      the rest of the server should do!) for the stored-routine CREATE, we
      can construct a perfect statement from that information, instead of
      writing uncertain information from an unknown parser state.  
      Fortunately, there's already a function nearby that does exactly 
      that.
      ---
      Update for Bug#36570.  Qualify routine names with db name when
      writing to the binlog ONLY if the source text is qualified.
      573828aa
  6. 14 May, 2008 1 commit
    • cmiller@zippy.cornsilk.net's avatar
      Bug#36570: Parse error of CREATE PROCEDURE stmt with comments on \ · d48a925a
      cmiller@zippy.cornsilk.net authored
      	slave
      
      The stored-routine code took the contents of the (lowest) parser
      and copied it directly to the binlog, which causes problems if there
      is a special case of interpretation at the parser level -- which 
      there is, in the "/*!VER */" comments.  The trailing "*/" caused
      errors on the slave, naturally.
      
      Now, since by that point we have /properly/ created parse-tree (as 
      the rest of the server should do!) for the stored-routine CREATE, we
      can construct a perfect statement from that information, instead of
      writing uncertain information from an unknown parser state.  
      Fortunately, there's already a function nearby that does exactly 
      that.
      d48a925a
  7. 02 Apr, 2008 1 commit
  8. 07 Mar, 2008 1 commit
    • sven@riska.(none)'s avatar
      BUG#31168: @@hostname does not replicate · 81b1d712
      sven@riska.(none) authored
      Problem: in mixed and statement mode, a query that refers to a
      system variable will use the slave's value when replayed on
      slave. So if the value of a system variable is inserted into a
      table, the slave will differ from the master.
      Fix: mark statements that refer to a system variable as "unsafe",
      meaning they will be replicated by row in mixed mode and produce a warning
      in statement mode. There are some exceptions: some variables are actually
      replicated. Those should *not* be marked as unsafe.
      BUG#34732: mysqlbinlog does not print default values for auto_increment variables
      Problem: mysqlbinlog does not print default values for some variables,
      including auto_increment_increment and others. So if a client executing
      the output of mysqlbinlog has different default values, replication will
      be wrong.
      Fix: Always print default values for all variables that are replicated.
      I need to fix the two bugs at the same time, because the test cases would
      fail if I only fixed one of them.
      81b1d712
  9. 01 Feb, 2008 2 commits
  10. 08 Jan, 2008 1 commit
  11. 17 Dec, 2007 1 commit
    • hezx@hezx.(none)'s avatar
      BUG#32205 Replaying statements from mysqlbinlog fails with a syntax error, replicates · 3255237f
      hezx@hezx.(none) authored
      fine
      
      The reason of this bug is that when mysqlbinlog dumps a query, the query is written to
      output with a delimeter appended right after it, if the query string ends with a '--'
      comment, then the delimeter would be considered as part of the comment, if there are any
      statements after this query, then it will cause a syntax error.
      
      Start a newline before appending delimiter after a query string
      3255237f
  12. 15 Dec, 2007 1 commit
    • hezx@hezx.(none)'s avatar
      BUG#32205 Replaying statements from mysqlbinlog fails with a syntax error, replicates fine · c2f00cc3
      hezx@hezx.(none) authored
      The reason of this bug is that when mysqlbinlog dumps a query, the query is written to
      output with a delimeter appended right after it, if the query string ends with a '--'
      comment, then the delimeter would be considered as part of the comment, if there are any
      statements after this query, then it will cause a syntax error.
      
      Start a newline before appending delimiter after a query string
      c2f00cc3
  13. 12 Dec, 2007 1 commit
    • msvensson@pilot.mysql.com's avatar
      WL#4189 · d918988b
      msvensson@pilot.mysql.com authored
       - dynamic configuration support
       - safe process
       - cleanups
       - create new suite for fedarated
      d918988b
  14. 23 Nov, 2007 1 commit
  15. 12 Nov, 2007 1 commit
  16. 09 Nov, 2007 1 commit
    • mats@capulet.net's avatar
      BUG#31793 (log event corruption causes crash): · a432d3de
      mats@capulet.net authored
      When running mysqlbinlog on a 64-bit machine with a corrupt relay log,
      it causes mysqlbinlog to crash. In this case, the crash is caused
      because a request for 18446744073709534806U bytes is issued, which
      apparantly can be served on a 64-bit machine (speculatively, I assume)
      but this causes the memcpy() issued later to copy the data to segfault.
      
      The request for the number of bytes is caused by a computation
      of data_len - server_vars_len where server_vars_len is corrupt in such
      a sense that it is > data_len. This causes a wrap-around, with the
      the data_len given above.
      
      This patch adds a check that if server_vars_len is greater than
      data_len before the substraction, and aborts reading the event in
      that case marking the event as invalid. It also adds checks to see
      that reading the server variables does not go outside the bounds
      of the available space, giving a limited amount of integrity check.
      a432d3de
  17. 03 Nov, 2007 1 commit
  18. 01 Aug, 2007 1 commit
  19. 20 Jun, 2007 1 commit
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #28293. · 1b5d8931
      gshchepa/uchum@gleb.loc authored
      Occasionally mysqlbinlog --hexdump failed with error:
        ERROR 1064 (42000) at line ...: You have an error in your
        SQL syntax; check the manual that corresponds to your MySQL
        server version for the right syntax to use near
        'Query thread_id=... exec_time=... error_code=...
      
      When the length of hexadecimal dump of binlog header was
      divisible by 16, commentary sign '#' after header was lost.
      The Log_event::print_header function has been modified to always
      finish hexadecimal binlog header with "\n# ".
      1b5d8931
  20. 02 Apr, 2007 1 commit
  21. 31 Mar, 2007 1 commit
  22. 07 Mar, 2007 1 commit
  23. 01 Mar, 2007 4 commits
  24. 28 Feb, 2007 2 commits
    • bar@mysql.com's avatar
      After merge fix · c48a5e8b
      bar@mysql.com authored
      c48a5e8b
    • bar@mysql.com's avatar
      Bug#15126 character_set_database is not replicated (LOAD DATA INFILE need it) · dd0c43d5
      bar@mysql.com authored
      This patch fixes problem that LOAD DATA could use different
      character sets when loading files on master and on slave sides:
      - Adding replication of thd->variables.collation_database
      - Adding optional character set clause into LOAD DATA
      
      Note, the second way, with explicit CHARACTER SET clause
      should be the recommended way to load data using an alternative
      character set.
      The old way, using "SET @@character_set_database=xxx" should be
      gradually depricated.
      dd0c43d5
  25. 19 Feb, 2007 1 commit
    • kaa@polly.local's avatar
      Bug#18743: Several test cases fails if "classic" configuration in 5.0 · 315819fe
      kaa@polly.local authored
      The problem happened because those tests were using "cp932" and "ucs2" without checking whether these character sets are available. This fix moves test parts to make character set specific parts be tested only if they are:
      - some parts were moved to "ctype_ucs.test" and "ctype_cp932.test"
      - some parts were moved to the newly added tests "innodb-ucs2.test", "mysqlbinglog-cp932.test" and "sp-ucs2.test"
      315819fe
  26. 22 Jan, 2007 1 commit
  27. 14 Dec, 2006 1 commit
    • bar@mysql.com/bar.intranet.mysql.r18.ru's avatar
      Bug#17642 mysqlbinlog: Restore from row-based binlog fails · ba6529d7
      Problem: mysqlbinlog_base64 failed sporadically.
      
      Reason: Missing "flush logs" before running $MYSQL_BINLOG,
      which could start dumping the log file before server
      has finished writting into it.
      Fix:
      - implementing --force-if-open option to "mysqlbinlog"
      - adding --disable-force-if-open to make $MYSQL_BINLOG
        fail on non-closed log files, to garantee that nobody
        will forget "flush logs" in the future.
      - adding "flush logs" into all affected tests.
      ba6529d7
  28. 07 Dec, 2006 1 commit
  29. 28 Nov, 2006 1 commit
  30. 31 May, 2006 1 commit
  31. 16 May, 2006 1 commit
  32. 09 May, 2006 1 commit
    • aelkin@mysql.com's avatar
      BUG#14157: utf8 encoding in binlog without set character_set_client e.g DROP temporary · 226d978a
      aelkin@mysql.com authored
      Binlog lacks encoding info about DROPped temporary table.
      
      Idea of the fix is to switch temporary to system_charset_info when a temporary table
      is DROPped for binlog. Since that is the server, that automatically, but not the client, who generates the query
      the binlog should be updated on the server's encoding for the coming DROP.
      The `write_binlog_with_system_charset()' is introduced to replace similar problematic places in the code.
      226d978a
  33. 10 Feb, 2006 1 commit
  34. 09 Feb, 2006 1 commit
    • aelkin@mysql.com's avatar
      BUG#16217 forced to introduce a separate mysql client command to adopt its · dd2a44c4
      aelkin@mysql.com authored
      internal charset to one associated with currently being handled query. 
      To note such a query can come from interactive client either.
      
      There was a discussion within replication team and Monty who's suggestion won.
      It avoids straightforward parsing of all `set' queries that could affect client side 
      character set. 
      According to the idea, mysql client does not parse `set' queries but rather cares of
      `charset new_cs_name' command.
      This command is generated by mysqlbinlog in form of exclaiming comment (Lars' suggestion)
      so that enlightened clients like `mysql' knows what to do with it.
      
      Interactive human can switch between many multi-byte charsets during the session 
      providing the command explicitly. 
      To note that setting new internal mysql's charset does not
      trigger sending any `SET' sql statement to the server. 
      dd2a44c4
  35. 24 Jan, 2006 1 commit