1. 30 Mar, 2011 1 commit
    • Sergey Glukhov's avatar
      Bug#11766126 59166: ANOTHER DATETIME VALGRIND UNINITIALIZED WARNING · 3b7f0445
      Sergey Glukhov authored
      Valgrind warning happens because null values check happens too late
      in Item_func_month::val_str(after result string calculation).The fix
      is to check null value before result string calculation.
      
      
      mysql-test/r/func_time.result:
        test case
      mysql-test/t/func_time.test:
        test case
      sql/item_timefunc.h:
        check null value before result string calculation.
      3b7f0445
  2. 29 Mar, 2011 1 commit
    • Jon Olav Hauglid's avatar
      Bug# 11763784 (former 56541) · 4e26a41f
      Jon Olav Hauglid authored
      ASSERTION TABLE->DB_STAT FAILED IN
      SQL_BASE.CC::OPEN_TABLE() DURING I_S Q
      
      This assert could be triggered if a statement requiring a name
      lock on a table (e.g. DROP TRIGGER) executed concurrently
      with an I_S query which also used the table.
      
      One connection first started an I_S query that opened a given table.
      Then another connection started a statement requiring a name lock
      on the same table. This statement was blocked since the table was
      in use by the I_S query. When the I_S query resumed and tried to
      open the table again as part of get_all_tables(), it would encounter
      a table instance with an old version number representing the pending
      name lock. Since I_S queries ignore version checks and thus pending
      name locks, it would try to continue. This caused it to encounter
      the assert. The assert checked that the TABLE instance found with a
      different version, was a real, open table. However, since this TABLE
      instance instead represented a pending name lock, the check would
      fail and trigger the assert.
      
      This patch fixes the problem by removing the assert. It is ok for
      TABLE::db_stat to be 0 in this case since the TABLE instance can
      represent a pending name lock.
      
      Test case added to lock_sync.test.
      4e26a41f
  3. 28 Mar, 2011 11 commits
  4. 25 Mar, 2011 3 commits
    • Sven Sandberg's avatar
      BUG#11766427, BUG#59539: Filter by server id in mysqlbinlog fails · f1b638d3
      Sven Sandberg authored
      Problem: mysqlbinlog --server-id may filter out Format_description_log_events.
      If mysqlbinlog does not process the Format_description_log_event,
      then mysqlbinlog cannot read the rest of the binary log correctly.
      This can have the effect that mysqlbinlog crashes, generates an error,
      or generates output that causes mysqld to crash, generate an error,
      or corrupt data.
      Fix: Never filter out Format_description_log_events. Also, never filter
      out Rotate_log_events.
      
      
      client/mysqlbinlog.cc:
        Process Format_description_log_events even when the
        server_id does not match the number given by --server-id.
      mysql-test/t/mysqlbinlog.test:
        Add test case.
      f1b638d3
    • Georgi Kodinov's avatar
      merge · 5af97358
      Georgi Kodinov authored
      5af97358
    • Georgi Kodinov's avatar
      Bug #11766769: 59959: SMALL VALUES OF --MAX-ALLOWED-PACKET · dcf6b68d
      Georgi Kodinov authored
      ARE NOT BEING HONORED
      
      max_allowed_packet works in conjunction with net_buffer_length.
      max_allowed_packet is an upper bound of net_buffer_length.
      So it doesn't make sense to set the upper limit lower than the value.
      Added a warning (using ER_UNKNOWN_ERRROR and a specific message)
      when this is done (in the log at startup and when setting either 
      max_allowed_packet or the net_buffer_length variables)
      Added a test case.
      Fixed several tests that broke the above rule.
      dcf6b68d
  5. 24 Mar, 2011 2 commits
    • Luis Soares's avatar
    • Luis Soares's avatar
      BUG#11766865: 60091: RBR + NO PK + UPDATE NULL VALUE --> SLAVE BREAK WITH ERROR HA_ERR_END_OF_ · b489c89f
      Luis Soares authored
        
      The slave was not able to find the correct row in the innodb
      table, because the row fetched from the innodb table would not
      match the before image. This happened because the (don't care)
      bytes in the NULLed fields would change once the row was stored
      in the storage engine (from zero to the default value). This
      would make bulk memory comparison (using memcmp) to fail.
        
      We fix this by taking a preventing measure and avoiding memcmp
      for tables that contain nullable fields. Therefore, we protect
      the slave search routine from engines that return arbitrary
      values for don't care bytes (in the nulled fields). Instead, the
      slave thread will only check null_bits and those fields that are
      not set to NULL when comparing the before image against the
      storage engine row.
      
      mysql-test/extra/rpl_tests/rpl_record_compare.test:
        Added test case to the include file so that this is tested 
        with more than one engine.
      mysql-test/suite/rpl/r/rpl_row_rec_comp_innodb.result:
        Result update.
      mysql-test/suite/rpl/r/rpl_row_rec_comp_myisam.result:
        Result update.
      mysql-test/suite/rpl/t/rpl_row_rec_comp_myisam.test:
        Moved the include file last, so that the result from
        BUG#11766865 is not intermixed with the result for
        BUG#11760454.
      sql/log_event.cc:
        Skips memory comparison if the table has nullable 
        columns and compares only non-nulled fields in the
        field comparison loop.
      b489c89f
  6. 23 Mar, 2011 1 commit
  7. 22 Mar, 2011 5 commits
    • Magne Mahre's avatar
      Null merge (from mysql-5.0) · 6093ae49
      Magne Mahre authored
      6093ae49
    • Magne Mahre's avatar
      Post-push fix for Bug 11896296 · 326b97cf
      Magne Mahre authored
      Didn't build on Solaris.
      326b97cf
    • Bjorn Munch's avatar
      merge from 5.1 main · 761ba834
      Bjorn Munch authored
      761ba834
    • Magne Mahre's avatar
      Null merge · 015f7bcf
      Magne Mahre authored
      015f7bcf
    • Magne Mahre's avatar
      Bug#11896296 REMOVE LGPL LICENSED FILES IN MYSQL 5.0 · 55e42237
      Magne Mahre authored
      The LGPL license is used in some legacy code, and to
      adhere to current licensing polity, we remove those
      files that are no longer used, and reorganize the
      remaining LGPL code so it will be GPL licensed from
      now on.
      
      Note:  This patch only removed LGPL licensed files
             in MySQL 5.0, and is the first of a set of
             patches to remove LGPL from all trees.
             (See Bug# 11840513 for details)
      
      
      
      include/my_compare.h:
        Mostly code moved in from my_handler
      include/my_global.h:
        AIX-only code.   Function used to be in my_port.c
        Inlining instead.
      libmysql/Makefile.shared:
        my_gethostbyname and my_port is removed
      myisam/mi_check.c:
        ha_find_null is moved from my_handler and made static.
      55e42237
  8. 21 Mar, 2011 5 commits
  9. 18 Mar, 2011 2 commits
  10. 17 Mar, 2011 2 commits
  11. 16 Mar, 2011 4 commits
  12. 15 Mar, 2011 2 commits
    • Bjorn Munch's avatar
      Bug #11762804 55442: MYSQLD DEBUG CRASHES WHILE RUNNING MYISAM_CRASH_BEFORE_FLUSH_KEYS.TEST · ebba068d
      Bjorn Munch authored
      This will cause affected tests to skip if CrashReporter would popup
      Found 5 tests that needed modification
      ebba068d
    • Dmitry Shulga's avatar
      Fixed Bug#11764168 "56976: SEVERE DENIAL OF SERVICE IN PREPARED STATEMENTS". · 9320dca9
      Dmitry Shulga authored
      The problem was that server didn't check resulting size of prepared
      statement argument which was set using mysql_send_long_data() API.
      By calling mysql_send_long_data() several times it was possible
      to create overly big string and thus force server to allocate
      memory for it. There was no way to limit this allocation.
      
      The solution is to add check for size of result string against
      value of max_long_data_size start-up parameter. When intermediate
      string exceeds max_long_data_size value an appropriate error message
      is emitted.
      
      We can't use existing max_allowed_packet parameter for this purpose
      since its value is limited by 1GB and therefore using it as a limit
      for data set through mysql_send_long_data() API would have been an
      incompatible change. Newly introduced max_long_data_size parameter
      gets value from max_allowed_packet parameter unless its value is
      specified explicitly. This new parameter is marked as deprecated
      and will be eventually replaced by max_allowed_packet parameter.
      Value of max_long_data_size parameter can be set only at server
      startup.
      
      
      mysql-test/t/variables.test:
        Added checking for new start-up parameter max_long_data_size.
      sql/item.cc:
        Added call to my_message() when accumulated string exceeds
        max_long_data_size value. my_message() calls error handler
        that was installed in mysql_stmt_get_longdata before call
        to Item_param::set_longdata.
        
        The error handler then sets state, last_error and last_errno
        fields for current statement to values which correspond to
        error which was caught.
      sql/mysql_priv.h:
        Added max_long_data_size variable declaration.
      sql/mysqld.cc:
        Added support for start-up parameter 'max_long_data_size'.
        This parameter limits size of data which can be sent from
        client to server using mysql_send_long_data() API.
      sql/set_var.cc:
        Added variable 'max_long_data_size' into list of variables
        displayed by command 'show variables'.
      sql/sql_prepare.cc:
        Added error handler class Set_longdata_error_handler.
        This handler is used to catch any errors that can be
        generated during execution of Item_param::set_longdata().
        
        Source code snippet that makes checking for statement's state 
        during statement execution is moved from Prepared_statement::execute()
        to Prepared_statement::execute_loop() in order not to call
        set_parameters() when statement has failed during
        set_long_data() execution. If this hadn't been done
        the call to set_parameters() would have failed.
      tests/mysql_client_test.c:
        A testcase for the bug #56976 was added.
      9320dca9
  13. 14 Mar, 2011 1 commit