1. 12 Dec, 2008 2 commits
    • Gleb Shchepa's avatar
      Bug #40761: Assert on sum function on · c1bf0475
      Gleb Shchepa authored
                  IF(..., CAST(longtext AS UNSIGNED), signed_val)
                  (was: LEFT JOIN on inline view crashes server)
      
      Select from a LONGTEXT column wrapped with an expression
      like "IF(..., CAST(longtext_column AS UNSIGNED), smth_signed)"
      failed an assertion or crashed the server. IFNULL function was
      affected too.
      
      LONGTEXT column item has a maximum length of 32^2-1 bytes,
      at the same time this is a maximum possible length of any
      MySQL item. CAST(longtext_column AS UNSIGNED) returns some
      unsigned numeric result of length 32^2-1, so the result of
      IF/IFNULL function of this number and some other signed number
      will have text length of (32^2-1)+1=32^2 (one byte for the
      minus sign) - there is integer overflow, and the length is
      equal to zero. That caused assert/crash.
      
      CAST AS UNSIGNED function has been modified to limit maximal
      length of resulting number to 67 (maximal length of DECIMAL
      and two characters for minus sign and dot).
      c1bf0475
    • Gleb Shchepa's avatar
      rollback of bug #40761 fix · 03f9b2ce
      Gleb Shchepa authored
      03f9b2ce
  2. 11 Dec, 2008 6 commits
    • Gleb Shchepa's avatar
      Bug #40761: Assert on sum function on · ce8ad64d
      Gleb Shchepa authored
                  IF(..., CAST(longtext AS UNSIGNED), signed_val)
                  (was: LEFT JOIN on inline view crashes server)
      
      Select from a LONGTEXT column wrapped with an expression
      like "IF(..., CAST(longtext_column AS UNSIGNED), smth_signed)"
      failed an assertion or crashed the server. IFNULL function was
      affected too.
      
      LONGTEXT column item has a maximum length of 32^2-1 bytes,
      at the same time this is a maximum possible length of any
      MySQL item. CAST(longtext_column AS UNSIGNED) returns some
      unsigned numeric result of length 32^2-1, so the result of
      IF/IFNULL function of this number and some other signed number
      will have text length of (32^2-1)+1=32^2 (one byte for the
      minus sign) - there is integer overflow, and the length is
      equal to zero. That caused assert/crash.
      
      The bug has been fixed by the same solution as in the CASE
      function implementation.
      ce8ad64d
    • Chad MILLER's avatar
      Merge from bugteam trunk. · f8b28604
      Chad MILLER authored
      f8b28604
    • Chad MILLER's avatar
      Bug#33812: mysql client incorrectly parsing DELIMITER · cf9126a0
      Chad MILLER authored
      Fix parsing of mysql client commands, especially in relation to
      single-line comments when --comments was specified.
      
      This is a little tricky, because we need to allow single-line
      comments in the middle of statements, but we don't want to allow
      client commands in the middle of statements. So in
      comment-preservation mode, we go ahead and send single-line
      comments to the server immediately when we encounter them on their
      own. 
      
      This is still slightly flawed, in that it does not handle a
      single-line comment with leading spaces, followed by a client-side
      command when --comment has been enabled. But this isn't a new
      problem, and it is quite an edge condition. Fixing it would require
      a more extensive overall of how the mysql client parses commands. 
      cf9126a0
    • Luis Soares's avatar
      Fix PB warnings for parenthesis and valgrind leak report. · e0f4556d
      Luis Soares authored
      BUG#38826
      e0f4556d
    • Sergey Glukhov's avatar
      fix for pushbuild failure on 64 linux · e419c5d3
      Sergey Glukhov authored
      e419c5d3
    • Sergey Glukhov's avatar
  3. 10 Dec, 2008 6 commits
  4. 09 Dec, 2008 11 commits
  5. 08 Dec, 2008 4 commits
  6. 05 Dec, 2008 1 commit
  7. 04 Dec, 2008 2 commits
    • Andrei Elkin's avatar
      Bug #33420 Test 'rpl_packet' fails randomly with changed "Exec_Master_Log_Pos" · cea55f3d
      Andrei Elkin authored
      Bug #41173 rpl_packet fails sporadically on pushbuild: query 'DROP TABLE t1' failed
      
      
      The both issues appeared to be a race between the SQL thread executing CREATE table t1
      and the IO thread that is expected to stop at the consequent big size event.
      The two events need serialization which is implemented.
      The early bug required back-porting a part fixes for bug#38350 exclusively for 5.0 version.
      cea55f3d
    • Luis Soares's avatar
      BUG#38826 Race in MYSQL_LOG::purge_logs is impossible to debug in production · 5726574b
      Luis Soares authored
      BUG#39325 Server crash inside MYSQL_LOG::purge_first_log halts replicaiton
      
      The patch reverses the order of the purging and updating events for log and relay-log.info/index files respectively.
      This solves the problem of having holes caused by crashes happening between updating info/index files and purging logs.
      
      NOTE: This is a combined patch for BUG#38826 and BUG#39325. This patch is based on bugteam tree and takes into account reviewers suggestions.
      5726574b
  8. 03 Dec, 2008 3 commits
  9. 02 Dec, 2008 1 commit
  10. 01 Dec, 2008 4 commits
    • Georgi Kodinov's avatar
    • Georgi Kodinov's avatar
      merged 5.0-main into 5.0-bugteam · f2a317b6
      Georgi Kodinov authored
      f2a317b6
    • Georgi Kodinov's avatar
      merged bug 39920 to 5.0-bugteam · d21c8503
      Georgi Kodinov authored
      d21c8503
    • Georgi Kodinov's avatar
      Bug #39920: MySQL cannot deal with Leap Second expression in string literal. · 8f36a23c
      Georgi Kodinov authored
                        
      Updated MySQL time handling code to react correctly on UTC leap second additions.
      MySQL functions that return the OS current time, like e.g. CURDATE(), NOW() etc
      will return :59:59 instead of :59:60 or 59:61.
      As a result the reader will receive :59:59 for 2 or 3 consecutive seconds 
      during the leap second.
      This fix will not affect the values returned by UNIX_TIMESTAMP() for leap seconds.
      But note that when converting the value returned by UNIX_TIMESTAMP() to broken 
      down time the correction of leap seconds will still be applied.
      Note that this fix will make a difference *only* if the OS is specially configured
      to return leap seconds from the OS time calls or when using a MySQL time zone 
      defintion that has leap seconds.
      Even after this change date/time literals (or other broken down time 
      representations) with leap seconds (ending on :59:60 or 59:61) will still be 
      considered illegal and discarded by the server with an error or 
      a warning depending on the sql mode.
      Added a test case to demonstrate the effect of the fix.
      8f36a23c