1. 16 Aug, 2011 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #824463. · be03fe9c
      Igor Babaev authored
      When merging a view / derived table the function SELECT_LEX::merge_subquery
      incorrectly updated the list SELECT_LEX::leaf_tables. Erroneously it
      appended the leaf_tables list of the merged object L and then removed the
      reference to the merged object T from the SELECT_LEX::leaf_tables list.
      A correct implementation should insert the list L into the
      SELECT_LEX::leaf_tables list in place of the element of the list that 
      refers to T.
      The bug could lead to wrong results or even crashes for queries with
      nested outer joins over views / derived tables.
      be03fe9c
  2. 15 Aug, 2011 5 commits
    • Michael Widenius's avatar
      Automatic merge with 5.2 · fb135f7e
      Michael Widenius authored
      fb135f7e
    • Michael Widenius's avatar
      Merge in bug fix from 5.1 · b5f830d8
      Michael Widenius authored
      b5f830d8
    • Michael Widenius's avatar
      Increase server version · 8740e596
      Michael Widenius authored
      8740e596
    • Michael Widenius's avatar
      Fixed bug lp:826377 "Aria DB Format: Reading specific table from dump causes Wrong bytesec" · e71eb27a
      Michael Widenius authored
      The bug was that when using bulk insert combined with lock table, we intitalized the io cache with the wrong file position.
      This fixed a bug where MariaDB could not read in a table dump done with mysqldump.
      
      
      mysql-test/suite/maria/r/locking.result:
        Test case for locking + write cache bug
      mysql-test/suite/maria/t/locking.test:
        Test case for locking + write cache bug
      storage/maria/ma_extra.c:
        Initialize write cache used with bulk insert to correct file length.
        (The old code didn't work if one was using LOCK TABLE for the given table).
      e71eb27a
    • Michael Widenius's avatar
      Fixes bugs found by testcase for lp:815022 and lp:726374 "ma_blockrec.c:3000:... · b95d2778
      Michael Widenius authored
      Fixes bugs found by testcase for lp:815022 and lp:726374 "ma_blockrec.c:3000: write_block_record: Assertion `cur_block[1].page_count == 0' failed with a multi-index Aria workload"
      The issues was:
      - For some tables with a lot of not packed fields, we didn't allocate enough memory in head page which caused DBUG_ASSERT's
      - Removed wrong DBUG_ASSERT()
      - Fixed a problem with underflow() where it generates a key page where all keys didn't fit.
      - Max key length is now limited by block_size/3  (was block_size /2).  This is required for underflow() to work with packed keys.
      
      
      
      
      mysql-test/lib/v1/mysql-test-run.pl:
        Remove --alignment=8 as this doesn't work on 64 bit systems
      mysql-test/suite/maria/r/small_blocksize.result:
        Test case for Aria bug
      mysql-test/suite/maria/t/small_blocksize-master.opt:
        Test case for Aria bug
      mysql-test/suite/maria/t/small_blocksize.test:
        Test case for Aria bug
      storage/maria/ha_maria.cc:
        Fixed comment
      storage/maria/ma_bitmap.c:
        Fixed wrong variable usage in find_where_to_split_row() where we allocated too little memory for head page.
        We did not take into account space for head extents (long VARCHAR) when trying to split row on head page. This caused us to allocate too little space from bitmap which lead to ASSERT failures later.
      storage/maria/ma_blockrec.c:
        Made some argument const (to ensure they was not accidently changed)
        Removed wrong DBUG_ASSERT()
      storage/maria/ma_blockrec.h:
        Removed not used variable
      storage/maria/ma_delete.c:
        Added my_afree() in case of error
        More comments and DBUG_ASSERT() for underflow()
      storage/maria/ma_open.c:
        Make keyinfo->underflow_block_length smaller for packed keys. This has to be done as for long packed keys, underflow() otherwise generates a key page where all keys didn't fit.
      storage/maria/ma_page.c:
        New DBUG_ASSERT()
      storage/maria/ma_write.c:
        Fixed comment
      storage/maria/maria_def.h:
        We have to have space for at least 3 keys on a key page.
        (Otherwise the underflow() code doesn't work for packed keys, even when we have an underflow() for an empty key page)
      b95d2778
  3. 12 Aug, 2011 8 commits
  4. 11 Aug, 2011 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #823826. · 4ddea0cb
      Igor Babaev authored
      The method Item_func_isnull::update_used_tables() erroneously did not
      update cached values stored in the fields used_tables_cache and
      const_item_cache of the Item_func_isnull objects. As a result the
      Item_func_isnull::used_tables() returned wrong bitmaps and, as a
      consequence, push-down predicates could be attached to wrong tables.
      4ddea0cb
  5. 10 Aug, 2011 2 commits
    • Michael Widenius's avatar
      Fixed bug lp:814054 'Assertion `block->hash_link == hash_link &&... · b5ef802f
      Michael Widenius authored
      Fixed bug lp:814054 'Assertion `block->hash_link == hash_link && hash_link->block == block' in ma_pagecache.c:2275 with Aria'
      - Replaced old DBUG_ASSERT with a new correct one + a comment.
      
      storage/maria/ma_pagecache.c:
        Replaced old DBUG_ASSERT with a new correct one + a comment.
      b5ef802f
    • Michael Widenius's avatar
      Fixes MySQL bug#48972: mysqldump --insert-ignore leaves set unique_checks=0. · 397fc34f
      Michael Widenius authored
      This fixes a bug that when you use mysqldump --no-create-info to generate a dump that you want to merge with an existing table,
      you can get an innodb table with duplicated unique keys.
      Patch orignally by Eric Bergen.
      
      
      client/mysqldump.c:
        Only use UNIQUE_CHECKS=0 for tables that are created.
        This solves the issue that you can't get duplicate unique keys when merging two dumps.
      mysql-test/r/mysqldump.result:
        Test for mysqldump --no-create-info
      397fc34f
  6. 09 Aug, 2011 3 commits
    • unknown's avatar
      Bug lp:781508: Take relevant test cases from MySQL 5.6 feature preview trees · 20968257
      unknown authored
      Identified all test cases in the MySQL file subquery_mat.inc that are
      not present in MariaDB. In total found 8 test cases for the following
      MySQL bugs:
      * BUG#49630 - not a bug in MariaDB, added test case
      * BUG#52538 - not a bug in MariaDB, added test case (checked with VG)
      * BUG#53103 - not a bug in MariaDB, added test case
      * BUG#54511 - not a bug in MariaDB, added test case
      * BUG#56367 - not a bug in MariaDB, added test case
      * BUG#59833 - not a bug in MariaDB, added test case
      * BUG#11852644 - not a bug in MariaDB, added test case
      * BUG#12668294 - not a bug in MariaDB, added test case
      
      All of these MySQL bugs are not present in MariaDB 5.3.
      
      The comparison was based on the following version of
      mysql-trunk:
      
      revno: 3350 [merge]
      committer: Marko Mäkelä <marko.makela@oracle.com>
      branch nick: mysql-trunk
      timestamp: Mon 2011-08-08 12:42:09 +0300
      message:
        Merge mysql-5.5 to mysql-trunk.
      20968257
    • unknown's avatar
      Fix bug lp:817384 · a6037394
      unknown authored
      This bug is a special case of lp:813447.
      
      Analysis:
      Constant optimization finds that the condition t2.a = 1
      can be used to access the primary key of table 't2'. As
      a result both outer table t1,t2 are considered as constant
      when we reach the execution phase. At the same time, during
      constant optimization, the IN predicate is not evaluated
      because it is expensive.
      
      When execution of the outer query reaches do_select(),
      control flow enter the branch:
      if (join->table_count == join->const_tables)
      { ... }
      This branch checks only the WHERE and HAVING clauses,
      but doesn't check the ON clauses of the query. Since the
      IN predicate was not evaluated during optimization, it is
      not evaluated at all, thus execution doesn't detect that
      the ON clause is FALSE.
      
      Solution:
      Similar to the patch for bug lp:813447, exclude system
      tables from constant substitution based on unique key
      lookups if there is an expensive ON condition on the
      inner table.
      a6037394
    • Igor Babaev's avatar
      Fixed LP bug #819716. · b7e9713e
      Igor Babaev authored
      Do not optimize derived table for the second time ever.
      b7e9713e
  7. 08 Aug, 2011 7 commits
    • Sergey Petrunya's avatar
      Merge fix for BUG#822134 · 2ea5096c
      Sergey Petrunya authored
      2ea5096c
    • Sergey Petrunya's avatar
      BUG#822134: Invalid plan and wrong result set for Q20 from DBT3 benchmark set · 81335120
      Sergey Petrunya authored
      - create_ref_for_key() has the code that walks KEYUSE array and tries to use
        maximum number of keyparts for ref (and eq_ref and ref_or_null) access.
        When one constructs ref access for table that is inside a SJ-Materialization
        nest, it is not possible to use tables that are ouside the nest (because 
        materialization is performed before they have any "current value").
        The bug was caused by this function not taking this into account.
      81335120
    • Sergey Petrunya's avatar
      Merge · b468a80e
      Sergey Petrunya authored
      b468a80e
    • Sergey Petrunya's avatar
      Update test results for previous cset · 0c459a01
      Sergey Petrunya authored
      0c459a01
    • Vladislav Vaintroub's avatar
      Fix long xtradb shutdown on Windows XP · fcb29391
      Vladislav Vaintroub authored
      The reason for the long shutdown is hanging in io threads. It appears
      that just closing completion port on XP does not necessarily signal 
      thread waiting in GetIOCompletionStatus() (even if this works fine
      on later Windows versions)
      
      The fix is to wakeup background threads using PostQueuedCompletionStatus()
      with a special 'key' parameter indicating shutdown.
      fcb29391
    • Vladislav Vaintroub's avatar
      LPBUG#882689 - crash during startup on XP. · 0a837698
      Vladislav Vaintroub authored
      The reason for the crash is Innodb assertion after trying to load condition variables function
      dynamically and not finding them
      
      The fix is to skip dynamic loading if srv_use_native_conditions is FALSE. srv_use_native_conditions 
      is derived from Windows version and would be FALSE on XP and TRUE on later Windows.
      
      This is the same handling as in MySQL 5.. In Maria 5.3 srv_use_native_conditions check was 
      presumably  lost in the downporting.
      0a837698
    • Michael Widenius's avatar
      Optimize mutex usage. · cfd2725d
      Michael Widenius authored
      storage/maria/ma_blockrec.c:
        Unlock bitmaps earlier (no reason to have them unlocked over _ma_write_clr())
      storage/maria/ma_extra.c:
        Don't lock THR_LOCK_maria for HA_EXTRA_PREPARE_FOR_RENAME (upper level ensures that we are not opening the same table during this call)
        We don't need to have share->intern_lock locked over _ma_flush_table_files()
      storage/maria/ma_open.c:
        Update comment
      cfd2725d
  8. 05 Aug, 2011 2 commits
    • Sergey Petrunya's avatar
      Merge · 1d1d8651
      Sergey Petrunya authored
      1d1d8651
    • Sergey Petrunya's avatar
      Backport of: · 0e19f3e3
      Sergey Petrunya authored
      revno: 2876.47.174
      revision-id: jorgen.loland@oracle.com-20110519120355-qn7eprkad9jqwu5j
      parent: mayank.prasad@oracle.com-20110518143645-bdxv4udzrmqsjmhq
      committer: Jorgen Loland <jorgen.loland@oracle.com>
      branch nick: mysql-trunk-11765831
      timestamp: Thu 2011-05-19 14:03:55 +0200
      message:
        BUG#11765831: 'RANGE ACCESS' MAY INCORRECTLY FILTER 
                              AWAY QUALIFYING ROWS
              
        The problem was that the ranges created when OR'ing two 
        conditions could be incorrect. Without the bugfix, 
        "I <> 6 OR (I <> 8 AND J = 5)" would create these ranges:
        
        "NULL < I < 6",
        "6 <= I <= 6 AND 5 <= J <= 5",
        "6 < I < 8",
        "8 <= I <= 8 AND 5 <= J <= 5",
        "8 < I"
        
        While the correct ranges is
        "NULL < I < 6",
        "6 <= I <= 6 AND 5 <= J <= 5",
        "6 < I"
        
        The problem occurs when key_or() ORs
        (1) "NULL < I < 6, 6 <= I <= 6 AND 5 <= J <= 5, 6 < I" with 
        (2) "8 < I AND 5 <= J <= 5"
        
        The reason for the bug is that in key_or(), SEL_ARG *tmp is 
        used to point to the range in (1) above that is merged with 
        (2) while key1 points to the root of the red-black tree of 
        (1). When merging (1) and (2), tmp refers to the "6 < I" 
        part whereas the root is the "6 <= ... AND 5 <= J <= 5" part. 
        
        key_or() decides that the tmp range needs to be split into
        "6 < I < 8, 8 <= I <= 8, 8 < I", in which next_key_part of the 
        second range should be that of tmp. However, next_key_part is
        set to key1->next_key_part ("5 <= J <= 5") instead of 
        tmp->next_key_part (empty). Fixing this gives the correct but
        not optimal ranges:
        "NULL < I < 6",
        "6 <= I <= 6 AND 5 <= J <= 5",
        "6 < I < 8",
        "8 <= I <= 8",
        "8 < I"
        
        A second problem can be seen above: key_or() may create 
        adjacent ranges that could be replaced with a single range. 
        Fixes for this is also included in the patch so that the range
        above becomes correct AND optimal:
        "NULL < I < 6",
        "6 <= I <= 6 AND 5 <= J <= 5",
        "6 < I"
        
        Merging adjacent ranges like this gives a slightly lower cost 
        estimate for the range access.
      0e19f3e3
  9. 04 Aug, 2011 1 commit
    • Sergey Petrunya's avatar
      Backport of: · 332b47d7
      Sergey Petrunya authored
      revno: 3363.3.16
      revision-id: jorgen.loland@oracle.com-20110506132631-5wickj6dvrh1dpj6
      parent: alexander.nozdrin@oracle.com-20110506132138-46459va9vcbd4nz0
      committer: Jorgen Loland <jorgen.loland@oracle.com>
      branch nick: mysql-trunk-11765831
      timestamp: Fri 2011-05-06 15:26:31 +0200
      message:
        BUG#11765831: 'RANGE ACCESS' MAY INCORRECTLY FILTER
                      AWAY QUALIFYING ROWS
      
        Preparation patch (does not include fix for the bug):
      
         * Extensively document key_or()
         * Remove tab indentations from key_or()
         * Minor code changes like using existing utility functions
           in key_or()
      332b47d7
  10. 03 Aug, 2011 2 commits
  11. 01 Aug, 2011 2 commits
  12. 31 Jul, 2011 3 commits
    • unknown's avatar
      Automerge 5.2->5.3 · efcb48f2
      unknown authored
      efcb48f2
    • unknown's avatar
      Automerge 5.1->5.2 · 0b56ae29
      unknown authored
      0b56ae29
    • unknown's avatar
      Speed up mysql-test-run.pl. · 47c23a11
      unknown authored
      Problem was the parsing of test suite files for various tags and options.
      This was done inefficiently, and include files were re-parsed for every
      place they were included. This caused a delay of 20 seconds or so before
      the first test started to run.
      
      By parsing more efficiently and re-using first parse for subsequent
      inclusion of the same file, time spent parsing is reduced to less than
      1 second, and start appears instantaneous.
      
      (With this patch, full ./mtr runs in 3 minutes on my laptop (release
      build.)
      
      mysql-test/suite/innodb_plugin/t/innodb_bug52663.test:
        Test is fairly slow, so try to avoid getting stuck with it at the end
        while other workers are idle.
      47c23a11
  13. 30 Jul, 2011 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #817360. · 103c4461
      Igor Babaev authored
      This problem could be observed for queries with nested outer joins
      for which the not_exist optimization were applicable. 
      The problem was caused by the code of the patch for bug #49322
      that erroneously forced the return to the previous nested loop
      level when the join algorithm successfully builds a partial record
      for an embedded outer to which the not_exist optimization could be
      applied.
      Actually the immediate return to the previous nested loops level
      is correct only if this partial record is rejected by a predicate
      pushed down to one of the inner tables of this outer join. Otherwise
      attempts to find extensions of this record must be made.
      103c4461
  14. 28 Jul, 2011 1 commit
  15. 26 Jul, 2011 1 commit
    • Michael Widenius's avatar
      Merge with 5.1 · 1d61f713
      Michael Widenius authored
      Fixed lp:814237: Wrong mutex usage in Aria
      
      
      storage/maria/ma_bitmap.c:
        Added call to _ma_bitmap_mark_file_changed() when flushing bitmap. This fixes lp:814237
      1d61f713