1. 07 May, 2010 6 commits
  2. 05 May, 2010 4 commits
    • Alexander Nozdrin's avatar
      Patch for Bug#50511 (Sometimes wrong handling of user variables containing NULL). · d91c271b
      Alexander Nozdrin authored
            
      The bug happened under the following condition:
        - there was a user variable of type REAL, containing NULL value
        - there was a table with a NOT_NULL column of any type but REAL, having
          default value (or auto increment);
        - a row was inserted into the table with the user variable as value.
          A warning was emitted here.
      
      The problem was that handling of NULL values of REAL type was not properly
      implemented: it didn't expect that REAL NULL value can be assigned to other
      data type.
      
      Basically, the problem was that set_field_to_null() was used instead of
      set_field_to_null_with_conversions().
      
      The fix is to use the right function, or more generally, to allow conversion of
      REAL NULL values to other data types.
      d91c271b
    • Alexander Barkov's avatar
      Bug#51571 load xml infile causes server crash · 25d31b8f
      Alexander Barkov authored
        
        Problem:
        item->name was NULL for Item_user_var_as_out_param
        which made strcmp(something, item->name) crash in the LOAD XML code.
        
        Fix:
        - item_func.h: Adding set_name() in constuctor for Item_user_var_as_out_param
        - sql_load.cc: Changing the condition in write_execute_load_query_log_event() which
        distiguished between Item_user_var_as_out_param and Item_field
        from
          if (item->name == NULL)
        to
          if (item->type() == Item::FIELD_ITEM)
        - loadxml.result, loadxml.test: adding tests
      25d31b8f
    • Alexander Barkov's avatar
      Bug#52849 [Com]: datetime index not work · 6bf10a86
      Alexander Barkov authored
      Problem: after introduction of "WL#2649 Number-to-string conversions"
      
      This query:
        SET NAMES cp850; -- Or any other non-latin1 ASCII-based character set
        SELECT * FROM t1
        WHERE datetime_column='2010-01-01 00:00:00'
      started to add extra character set conversion: 
        SELECT * FROM t1
        WHERE CONVERT(datetime_column USING cp850)='2010-01-01 00:00:00';
      
      so index on DATETIME column was not used anymore.
      Fix:
        avoid convertion of NUMERIC/DATETIME items
        (i.e. those with derivation DERIVATION_NUMERIC).
      6bf10a86
    • Horst.Hunger's avatar
      Patch for 47759 to trunk-bugfixing. · 8975d476
      Horst.Hunger authored
      8975d476
  3. 04 May, 2010 4 commits
  4. 03 May, 2010 2 commits
    • Kristofer Pettersson's avatar
      Automerge · 83fb8a77
      Kristofer Pettersson authored
      83fb8a77
    • Kristofer Pettersson's avatar
      Bug#50373 --secure-file-priv="" · 5b6ebdf0
      Kristofer Pettersson authored
      Iterative patch improvement. Previously committed patch
      caused wrong result on Windows. The previous patch also
      broke secure_file_priv for symlinks since not all file
      paths which must be compared against this variable are
      normalized using the same norm.
      
      The server variable opt_secure_file_priv wasn't
      normalized properly and caused the operations
      LOAD DATA INFILE .. INTO TABLE ..
      and
      SELECT load_file(..)
      to do different interpretations of the 
      --secure-file-priv option.
           
      The patch moves code to the server initialization
      routines so that the path always is normalized
      once and only once.
            
      It was also intended that setting the option
      to an empty string should be equal to 
      lifting all previously set restrictions. This
      is also fixed by this patch.
      5b6ebdf0
  5. 01 May, 2010 1 commit
  6. 30 Apr, 2010 4 commits
    • Alexander Nozdrin's avatar
      Patch for Bug#52356: query_cache_debug fails on Linux. · c784ee27
      Alexander Nozdrin authored
      There were two problems here:
        1. misleading error message
        2. abusing KILL QUERY in the test case
      
      1. The server reported "'DELETE FROM t1' failed: 1689: Wait on a lock was
      aborted due to a pending exclusive lock", while the proper error message
      should be "'DELETE FROM t1' failed: 1317: Query execution was interrupted".
      
      The problem is that the server has two different flags for
      signalling that a query is being killed: THD::killed and
      mysys_var::abort. The test case triggers a race: sometimes
      mysys_var::abort is set earlier than THD::killed. That leads
      to the following situation:
      
        - thr_lock() checks mysys_var::abort and returns error status,
          since mysys_var::abort is set;
      
        - the caller (mysql_lock_tables()) gets an error from thr_lock(),
          but THD::killed is not set, so it decides that thr_lock() couldn't
          get a lock due to a pending exclusive lock.
      
      This is a known issue with the server and it's not going to be fixed soon.
      
      5.5 differs from 5.1 here as follows: when thr_lock() returns an error:
        - 5.1 continues trying thr_lock() until success;
        - 5.5 propagates the error
      
      2. The test case uses KILL QUERY is a highly concurent environment.
      
      The fix is to wait for the dying statement to rest in peace before
      executing another DELETE FROM t1.
      c784ee27
    • Alexey Kopytov's avatar
      Automerge. · 0f5afe5d
      Alexey Kopytov authored
      0f5afe5d
    • Alexey Kopytov's avatar
      Bug #48419: another explain crash.. · 96366e11
      Alexey Kopytov authored
      WHERE predicates containing references to empty tables in a
      subquery were handled incorrectly by the optimizer when
      executing EXPLAIN. As a result, the optimizer could try to
      evaluate such predicates rather than just stop with
      "Impossible WHERE noticed after reading const tables" as 
      it would do in a non-subquery case. This led to valgrind 
      errors and crashes.
      
      Fixed the code checking the above condition so that subqueries
      are not excluded and hence are handled in the same way as top
      level SELECTs.
      96366e11
    • Vasil Dimov's avatar
      Disable innodb.innodb, main.ps_3innodb and main.partition_innodb_plugin · 8e6e1634
      Vasil Dimov authored
      mysql-tests because those emit (spurious?) valgrind warnings.
      8e6e1634
  7. 29 Apr, 2010 10 commits
  8. 28 Apr, 2010 9 commits
    • Georgi Kodinov's avatar
      Bug #47453: InnoDB incorrectly changes TIMESTAMP columns when JOINed · 70a96913
      Georgi Kodinov authored
      during an UPDATE
      
      Extended the fix for bug 29310 to multi-table update:
      
      When a table is being updated it has two set of fields - fields required for
      checks of conditions and fields to be updated. A storage engine is allowed
      not to retrieve columns marked for update. Due to this fact records can't
      be compared to see whether the data has been changed or not. This makes the
      server always update records independently of data change.
        
      Now when an auto-updatable timestamp field is present and server sees that
      a table handle isn't going to retrieve write-only fields then all of such
      fields are marked as to be read to force the handler to retrieve them.
      70a96913
    • Sven Sandberg's avatar
      BUG#50670: Slave stops with error code 1644 · a6518243
      Sven Sandberg authored
      Clarified error messages related to unsafe statements:
       - avoid the internal technical term "row injection"
       - use 'binary log' instead of 'binlog'
       - avoid the word 'unsafeness'
      a6518243
    • Vasil Dimov's avatar
      Bug#53046 dict_update_statistics_low can still be run concurrently · 792ea1f6
      Vasil Dimov authored
      on same table
      
      Followup to vasil.dimov@oracle.com-20100428102033-dt3caf531rs3lidr :
      
      Add more asserions, which I forgot.
      792ea1f6
    • Alexander Nozdrin's avatar
      After-merge fixes. · 72ae25b1
      Alexander Nozdrin authored
      72ae25b1
    • Vasil Dimov's avatar
      Revert the fix of Bug#38996 Race condition in ANALYZE TABLE · 7cf27d38
      Vasil Dimov authored
      This is branches/zip@r6032 in SVN and _is part_ of
      revid:svn-v4:16c675df-0fcb-4bc9-8058-dcc011a37293:branches/zip:6113
      in BZR.
      
      This is being reverted because now the code is serialized directly on
      index->stat_n_diff_key_vals[] as the fix for
      Bug#53046 dict_update_statistics_low can still be run concurrently on same table
      goes.
      7cf27d38
    • Vasil Dimov's avatar
      Followup to vasil.dimov@oracle.com-20100428084627-wtrmc66wqvjsdgj7: · 1a489632
      Vasil Dimov authored
      Address Marko's suggestions wrt the fix of
      Bug#53046 dict_update_statistics_low can still be run concurrently
      on same table
      1a489632
    • Vasil Dimov's avatar
      Fix Bug#53046 dict_update_statistics_low can still be run concurrently · 90fa66ab
      Vasil Dimov authored
      on same table
      
      Protect dict_index_t::stat_n_diff_key_vals[] with an array of
      mutexes.
      
      Testing: tested all code paths under UNIV_SYNC_DEBUG
      for the one in dict_print() one has to enable the InnoDB table monitor:
      CREATE TABLE innodb_table_monitor (a int) ENGINE=INNODB;
      90fa66ab
    • Marko Makela's avatar
      Merge r6103 from InnoDB Plugin to the built-in InnoDB to fix Bug #53202: · 831f2c9c
      Marko Makela authored
        ------------------------------------------------------------------------
        r6103 | marko | 2009-10-26 15:46:18 +0200 (Mon, 26 Oct 2009) | 4 lines
        Changed paths:
           M /branches/zip/row/row0ins.c
      
        branches/zip: row_ins_alloc_sys_fields(): Zero out the system columns
        DB_TRX_ID, DB_ROLL_PTR and DB_ROW_ID, in order to avoid harmless
        Valgrind warnings about uninitialized data.  (The warnings were
        harmless, because the fields would be initialized at a later stage.)
        ------------------------------------------------------------------------
      831f2c9c
    • 's avatar
      Bug #51839 mixup of DDL causes slave to stop · fa28ba8b
      authored
      Stored routine DDL statements use statement-based replication
      regardless of the current binlog format. The problem here was
      that if a DDL statement failed during metadata lock acquisition
      or opening of mysql.proc, the binlog format would not be reset
      before returning. So the following DDL or DML statements are 
      binlogged with a wrong binlog format, which causes the slave 
      to stop.
      
      The problem can be resolved by grabbing an exclusive MDL lock firstly
      instead of clearing the current binlog format. So that the binlog
      format will not be affected when the lock grab returns directly with
      an error. The same way is taken to open a proc table for update.
      fa28ba8b