1. 31 Oct, 2007 1 commit
  2. 30 Oct, 2007 1 commit
    • unknown's avatar
      Merge abarkov@bk-internal.mysql.com:/home/bk/mysql-5.0 · c45171b0
      unknown authored
      into  mysql.com:/home/bar/mysql-work/mysql-5.0-rpl-merge
      
      
      mysql-test/r/ctype_utf8.result:
        Auto merged
      mysql-test/r/func_regexp.result:
        Auto merged
      mysql-test/t/ctype_utf8.test:
        Auto merged
      mysql-test/t/func_regexp.test:
        Auto merged
      sql/item_cmpfunc.cc:
        Auto merged
      sql/item_cmpfunc.h:
        Auto merged
      sql/sql_class.h:
        Auto merged
      sql/sql_insert.cc:
        Auto merged
      sql/sql_parse.cc:
        Auto merged
      sql/sql_update.cc:
        Auto merged
      mysql-test/r/ctype_ucs.result:
        After merge fix
      mysql-test/t/ctype_ucs.test:
        After merge fix
      c45171b0
  3. 26 Oct, 2007 2 commits
    • unknown's avatar
      Merge kindahl-laptop.dnsalias.net:/home/bkroot/mysql-5.0-rpl · 2d380a83
      unknown authored
      into  kindahl-laptop.dnsalias.net:/home/bk/b12691-mysql-5.0-rpl
      
      
      sql/slave.cc:
        Auto merged
      2d380a83
    • unknown's avatar
      BUG#12691 (Exec_master_log_pos corrupted with SQL_SLAVE_SKIP_COUNTER): · f01321fd
      unknown authored
        
      Adding code to keep skipping events while inside a transaction. Execution
      will start just after the transaction has been skipped.
      
      
      sql/slave.cc:
        Adding code to set the thd->options flag for the slave SQL thread
        even when BEGIN, ROLLBACK, COMMIT, and XID events are being skipped.
            
        Adding code to not decrease the slave skip counter from 1 to 0 if we
        are inside a transaction. This will keep the counter at 1, and keep
        skipping events, until a transaction terminator is read. At that point,
        the slave skip counter will be decreased to 0, and events will be read
        and executed instead of read and skipped.
      mysql-test/r/rpl_slave_skip.result:
        New BitKeeper file ``mysql-test/r/rpl_slave_skip.result''
      mysql-test/t/rpl_slave_skip-slave.opt:
        New BitKeeper file ``mysql-test/t/rpl_slave_skip-slave.opt''
      mysql-test/t/rpl_slave_skip.test:
        New BitKeeper file ``mysql-test/t/rpl_slave_skip.test''
      f01321fd
  4. 24 Oct, 2007 3 commits
  5. 23 Oct, 2007 15 commits
  6. 22 Oct, 2007 4 commits
    • unknown's avatar
      Bug #28687: Search fails on '0000-00-00' date after sql_mode change · 849bcf94
      unknown authored
      When doing indexed search the server constructs a key image for 
      faster comparison to the stored keys. While doing that it must not
      perform (and stop if they fail) the additional date checks that can 
      be turned on by the SQL mode because there already may be values in 
      the table that don't comply with the error checks.
      Fixed by ignoring these SQL mode bits while making the key image.
      
      
      mysql-test/r/type_date.result:
        Bug #28687: test case
      mysql-test/t/type_date.test:
        Bug #28687: test case
      sql/item.cc:
        Bug #28687: no invalid date warnings
      849bcf94
    • unknown's avatar
      Fix for bug #31742: delete from ... order by function call that causes · bbce18c3
      unknown authored
      an error, asserts server
      
      In case of a fatal error during filesort in find_all_keys() the error
      was returned without the necessary handler uninitialization.
      Fixed by changing the code so that handler uninitialization is performed
      before returning the error.
      
      
      mysql-test/r/delete.result:
        Added a test case for bug #31742.
      mysql-test/t/delete.test:
        Added a test case for bug #31742.
      sql/filesort.cc:
        In case of a fatal error in find_all_keys() do not return before doing
        the necessary handler uninitialization steps.
      bbce18c3
    • unknown's avatar
      Merge bk@192.168.21.1:mysql-5.0-opt · 578c2386
      unknown authored
      into  mysql.com:/home/hf/work/30638/my50-30638
      
      
      578c2386
    • unknown's avatar
      Merge mysql.com:/home/hf/work/29801/my50-29801 · dda58628
      unknown authored
      into  mysql.com:/home/hf/work/30638/my50-30638
      
      
      dda58628
  7. 21 Oct, 2007 5 commits
    • unknown's avatar
      Merge tnurnberg@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · e763badf
      unknown authored
      into  mysql.com:/scratch/tnurnberg/31588/50-31588
      
      
      e763badf
    • unknown's avatar
      Merge polly.(none):/home/kaa/src/opt/bug28550/my50-bug28550 · fb434504
      unknown authored
      into  polly.(none):/home/kaa/src/opt/mysql-5.0-opt
      
      
      fb434504
    • unknown's avatar
      Bug #28550 "Potential bugs related to the return type of the CHAR function". · 04311fab
      unknown authored
        
      Since, as of MySQL 5.0.15, CHAR() arguments larger than 255 are converted into multiple result bytes, a single CHAR() argument can now take up to 4 bytes. This patch fixes Item_func_char::fix_length_and_dec() to take this into account.
        
      This patch also fixes a regression introduced by the patch for bug21513. As now we do not always have the 'name' member of Item set for Item_hex_string and Item_bin_string, an own print() method has been added to Item_hex_string so that it could correctly be printed by Item_func::print_args().
      
      
      mysql-test/r/func_str.result:
        Import patch bug288550.patch
      mysql-test/t/func_str.test:
        Import patch bug288550.patch
      sql/item.cc:
        Import patch bug288550.patch
      sql/item.h:
        Import patch bug288550.patch
      sql/item_strfunc.h:
        Import patch bug288550.patch
      04311fab
    • unknown's avatar
      Merge aelkin@bk-internal.mysql.com:/home/bk/mysql-5.0-rpl · e8b8b089
      unknown authored
      into  dsl-hkibras1-ff5fc300-23.dhcp.inet.fi:/home/elkin/MySQL/TEAM/FIXES/5.0/bug26199-create_proc_syntax_slave
      
      
      e8b8b089
    • unknown's avatar
      Bug #26199 Replication Failure on Slave when using stored procs with bit-type parameters. · 6cfd9a4f
      unknown authored
      The value of the actual argument of BIT-type-arg stored procedure was binlogged as non-escaped
      sequence of bytes corresponding to internal representation of the bit value.
      
      The patch enforces binlogging of the bit-argument as a valid literal: prefixing the quoted bytes
      sequence with _binary.
      Note, that behaviour of Item_field::var_str for field_type() of MYSQL_TYPE_BIT is exceptional
      in that the returned string contains the binary representation even though result_type() of
      the item is INT_RESULT.
      
      
      mysql-test/r/rpl_sp_effects.result:
        testing stored function and procedure called with BIT-arg.
      mysql-test/t/rpl_sp_effects.test:
        results changed
      sql/sp_head.cc:
        Treating BIT field type specially to for its value to be prefixed and quoted.
      6cfd9a4f
  8. 19 Oct, 2007 3 commits
  9. 18 Oct, 2007 6 commits
    • unknown's avatar
      Merge lambda.hsd1.co.comcast.net.:/home/malff/TREE/mysql-5.0-base · d9274610
      unknown authored
      into  lambda.hsd1.co.comcast.net.:/home/malff/TREE/mysql-5.0-rt-merge
      
      
      mysql-test/r/udf.result:
        Auto merged
      mysql-test/t/udf.test:
        Auto merged
      sql/item.cc:
        Auto merged
      sql/item_func.cc:
        Auto merged
      sql/mysql_priv.h:
        Auto merged
      sql/set_var.cc:
        Auto merged
      sql/udf_example.c:
        Auto merged
      sql/udf_example.def:
        Auto merged
      d9274610
    • unknown's avatar
      Merge tnurnberg@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · 0a47c29f
      unknown authored
      into  mysql.com:/scratch/tnurnberg/31588/50-31588
      
      
      0a47c29f
    • unknown's avatar
      Merge gkodinov@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · d5819c1f
      unknown authored
      into  magare.gmz:/home/kgeorge/mysql/autopush/B31221-5.0-opt
      
      
      d5819c1f
    • unknown's avatar
      Bug #31221: Optimizer incorrectly identifies impossible WHERE clause · 787a4b48
      unknown authored
       No warning was generated when a TIMESTAMP with a non-zero time part
       was converted to a DATE value. This caused index lookup to assume
       that this is a valid conversion and was returning rows that match 
       a comparison between a TIMESTAMP value and a DATE keypart.
       Fixed by generating a warning on such a truncation.
      
      
      mysql-test/r/derived.result:
        Bug #31221: fixed an existing not-precise test case
      mysql-test/r/ps_2myisam.result:
        Bug #31221: Warnings cased by existing tests
      mysql-test/r/ps_3innodb.result:
        Bug #31221: Warnings cased by existing tests
      mysql-test/r/ps_4heap.result:
        Bug #31221: Warnings cased by existing tests
      mysql-test/r/ps_5merge.result:
        Bug #31221: Warnings cased by existing tests
      mysql-test/r/ps_6bdb.result:
        Bug #31221: Warnings cased by existing tests
      mysql-test/r/ps_7ndb.result:
        Bug #31221: Warnings cased by existing tests
      mysql-test/r/type_date.result:
        Bug #31221: Warnings cased by existing tests
      mysql-test/r/type_datetime.result:
        Bug #31221: test case
      mysql-test/t/derived.test:
        Bug #31221: fixed an existing not-precise test case
      mysql-test/t/type_date.test:
        Bug #31221: test case
      sql/field.cc:
        Bug #31221: 
         - Upgraded fix for bug 29729
         - issue a warning only if the hh:mm:ss.msec is not zero consistently 
           for all the Field_newdate::store function
      sql/item_timefunc.cc:
        Bug #31221: don't ignore the errors when storing data
      787a4b48
    • unknown's avatar
      Bug #30638 why doesn't > 4294967295 rows work in myisam on windows. · fffd105f
      unknown authored
      The BIG_TABLES define wasn't enabled on Windows.
      #define added
      
      
      include/config-win.h:
        Bug #30638 why doesn't > 4294967295 rows work in myisam on windows.
        
        BIG_TABLES enabled on Windows
      fffd105f
    • unknown's avatar
      Merge tnurnberg@bk-internal.mysql.com:/home/bk/mysql-4.1-opt · 78a13fa4
      unknown authored
      into  sin.intern.azundris.com:/misc/mysql/31588/41-31588
      
      
      78a13fa4