An error occurred fetching the project authors.
  1. 02 Nov, 2012 2 commits
  2. 01 Nov, 2012 2 commits
  3. 31 Oct, 2012 5 commits
  4. 10 Oct, 2012 2 commits
    • unknown's avatar
      Fix of MDEV-3799. · 362c2bca
      unknown authored
      Find left table in right join (which turned to left join by reordering tables in join list but phisical order of tables of SELECT left as it was).
      362c2bca
    • Sergey Petrunya's avatar
      Backport of: olav.sandstaa@oracle.com-20120516074923-vd0dhp183vqcp2ql · d2d6c8b8
      Sergey Petrunya authored
      .. into MariaDB 5.3
      
      Fix for Bug#12667154 SAME QUERY EXEC AS WHERE SUBQ GIVES DIFFERENT
                           RESULTS ON IN() & NOT IN() COMP #3
      
      This bug causes a wrong result in mysql-trunk when ICP is used
      and bad performance in mysql-5.5 and mysql-trunk.
      
      Using the query from bug report to explain what happens and causes
      the wrong result from the query when ICP is enabled:
      
      1. The t3 table contains four records. The outer query will read
         these and for each of these it will execute the subquery.
      
      2. Before the first execution of the subquery it will be optimized. In
         this case the important is what happens to the first table t1:
         -make_join_select() will call the range optimizer which decides
          that t1 should be accessed using a range scan on the k1 index
          It creates a QUICK_RANGE_SELECT object for this.
         -As the last part of optimization the ICP code pushes the
          condition down to the storage engine for table t1 on the k1 index.
      
         This produces the following information in the explain for this table:
      
           2 DEPENDENT SUBQUERY t1 range k1 k1 5 NULL 3 Using index condition; Using filesort
      
         Note the use of filesort.
      
      3. The first execution of the subquery does (among other things) due
         to the need for sorting:
         a. Call create_sort_index() which again will call find_all_keys():
         b. find_all_keys() will read the required keys for all qualifying
            rows from the storage engine. To do this it checks if it has a
            quick-select for the table. It will use the quick-select for
            reading records. In this case it will read four records from the
            storage engine (based on the range criteria). The storage engine
            will evaluate the pushed index condition for each record.
         c. At the end of create_sort_index() there is code that cleans up a
            lot of stuff on the join tab. One of the things that is cleaned
            is the select object. The result of this is that the
            quick-select object created in make_join_select is deleted.
      
      4. The second execution of the subquery does the same as the first but
         the result is different:
         a. Call create_sort_index() which again will call find_all_keys()
            (same as for the first execution)
         b. find_all_keys() will read the keys from the storage engine. To
            do this it checks if it has a quick-select for the table. Now
            there is NO quick-select object(!) (since it was deleted in
            step 3c). So find_all_keys defaults to read the table using a
            table scan instead. So instead of reading the four relevant records
            in the range it reads the entire table (6 records). It then
            evaluates the table's condition (and here it goes wrong). Since
            the entire condition has been pushed down to the storage engine
            using ICP all 6 records qualify. (Note that the storage engine
            will not evaluate the pushed index condition in this case since
            it was pushed for the k1 index and now we do a table scan
            without any index being used).
            The result is that here we return six qualifying key values
            instead of four due to not evaluating the table's condition.
         c. As above.
      
      5. The two last execution of the subquery will also produce wrong results
         for the same reason.
      
      Summary: The problem occurs due to all but the first executions of the
      subquery is done as a table scan without evaluating the table's
      condition (which is pushed to the storage engine on a different
      index). This is caused by the create_sort_index() function deleting
      the quick-select object that should have been used for executing the
      subquery as a range scan.
      
      Note that this bug in addition to causing wrong results also can
      result in bad performance due to executing the subquery using a table
      scan instead of a range scan. This is an issue in MySQL 5.5.
      
      The fix for this problem is to avoid that the Quick-select-object that
      the optimizer created is deleted when create_sort_index() is doing
      clean-up of the join-tab. This will ensure that the quick-select
      object and the corresponding pushed index condition will be available
      and used by all following executions of the subquery.
      d2d6c8b8
  5. 09 Oct, 2012 1 commit
  6. 14 Oct, 2012 1 commit
  7. 05 Oct, 2012 1 commit
    • unknown's avatar
      Fix of MDEV-589. · b0d11675
      unknown authored
      The problem was in incorrect detection of merged views in tem_direct_view_ref::used_tables() .
      b0d11675
  8. 02 Oct, 2012 2 commits
  9. 01 Oct, 2012 1 commit
  10. 30 Sep, 2012 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #1058071 (mdev-564). · 66bd2b56
      Igor Babaev authored
      In some rare cases when the value of the system variable join_buffer_size
      was set to a number less than 256 the function JOIN_CACHE::set_constants 
      determined the size of an offset in the join buffer equal to 1 though
      the minimal join buffer required more than 256 bytes. This could cause
      a crash of the server when records from the join buffer were read.  
      66bd2b56
  11. 28 Sep, 2012 1 commit
  12. 27 Sep, 2012 4 commits
    • Sergei Golubchik's avatar
      merge · 352d7cad
      Sergei Golubchik authored
      352d7cad
    • unknown's avatar
      Merge from 5.1 · 807f537f
      unknown authored
      807f537f
    • unknown's avatar
    • Alexey Botchkov's avatar
      MDEV-495 backport --ignore-db-dir. · 8c2bb705
      Alexey Botchkov authored
      The feature was backported from MySQL 5.6.
      Some code was added to make commands as
              SELECT * FROM ignored_db.t1;
              CALL ignored_db.proc();
              USE ignored_db;
      to take that option into account.
      
      per-file comments:
        mysql-test/r/ignore_db_dirs_basic.result
              test result added.
        mysql-test/t/ignore_db_dirs_basic-master.opt
              options for the test,
              actually the set of --ignore-db-dir lines.
        mysql-test/t/ignore_db_dirs_basic.test
              test for the feature.
              Same test from 5.6 was taken as a basis,
              then tests for SELECT, CALL etc were added.
      
      per-file comments:
        sql/mysql_priv.h
      MDEV-495 backport --ignore-db-dir.
              interface for db_name_is_in_ignore_list() added.
        sql/mysqld.cc
      MDEV-495 backport --ignore-db-dir.
              --ignore-db-dir handling.
        sql/set_var.cc
      MDEV-495 backport --ignore-db-dir.
              the @@ignore_db_dirs variable added.
        sql/sql_show.cc
      MDEV-495 backport --ignore-db-dir.
              check if the directory is ignored.
        sql/sql_show.h
      MDEV-495 backport --ignore-db-dir.
              interface added for opt_ignored_db_dirs.
        sql/table.cc
      MDEV-495 backport --ignore-db-dir.
              check if the directory is ignored.
      8c2bb705
  13. 26 Sep, 2012 3 commits
  14. 25 Sep, 2012 1 commit
  15. 26 Sep, 2012 1 commit
  16. 24 Sep, 2012 3 commits
  17. 20 Sep, 2012 1 commit
    • unknown's avatar
      MDEV-521 fix. · 792efd59
      unknown authored
      After pullout item during single row subselect transformation it should be fixed properly.
      792efd59
  18. 17 Sep, 2012 1 commit
  19. 14 Sep, 2012 1 commit
    • unknown's avatar
      Fix bug lp:1009187, mdev-373, mysql bug#58628 · b917fb63
      unknown authored
      Analysis:
      The queries in question use the [unique | index]_subquery execution methods.
      These methods reuse the ref keys constructed by create_ref_for_key(). The
      way create_ref_for_key() works is that it doesn't store in ref.key_copy[]
      store_key elements that represent constants. In particular it doesn't store
      the store_key for NULL constants.
      
      The execution of [unique | index]_subquery calls
      subselect_uniquesubquery_engine::copy_ref_key, which in addition to copy
      the left IN argument into a index lookup key, is supposed to detect if
      the left IN argument contains NULLs. Since the store_key for the NULL
      constant is not copied into the key array, the null is not detected, and
      execution erroneously proceeds as if it should look for a complete match.
      
      Solution:
      The solution (unlike MySQL) is to reuse already computed information about
      NULL presence. Item_in_optimizer::val_int already finds out if the left IN
      operand contains NULLs. The fix propagates this to the execution methods
      subselect_[unique | index]subquery_engine::exec so it knows if there were
      NULL values independent of the presence of keys.
      
      In addition the patch siplifies copy_ref_key() and the logic that hanldes
      the case of NULLs in the left IN operand.
      b917fb63
  20. 07 Sep, 2012 1 commit
    • unknown's avatar
      Fix of MDEV-511. · 83bdf56e
      unknown authored
      As far as we reopen tables so TABLE become invalid we should remove the pointer on cleanup().
      83bdf56e
  21. 05 Sep, 2012 1 commit
    • unknown's avatar
      MDEV-486 LP BUG#1010116 fix. · 54bb28d4
      unknown authored
      Link view/derived table fields to a real table to check turning the table record to null row.
      
      Item_direct_view_ref wrapper now checks if table is turned to null row.
      54bb28d4
  22. 31 Aug, 2012 2 commits
    • Alexey Botchkov's avatar
      Bug #1043845 st_distance() results are incorrect depending on variable order. · 589c62fe
      Alexey Botchkov authored
              Autointersections of an object were treated as nodes, so the wrong result.
      
      per-file comments:
        mysql-test/r/gis.result
      Bug #1043845 st_distance() results are incorrect depending on variable order.
              test result updated.
        mysql-test/t/gis.test
      Bug #1043845 st_distance() results are incorrect depending on variable order.
              test case added.
        sql/item.cc
              small fix to make compilers happy.
        sql/item_geofunc.cc
      Bug #1043845 st_distance() results are incorrect depending on variable order.
              Skip intersection points when calculate distance.
      589c62fe
    • Sergei Golubchik's avatar
      compilation warning · 51e14492
      Sergei Golubchik authored
      51e14492
  23. 30 Aug, 2012 2 commits
    • unknown's avatar
      MDEV-381: fdatasync() does not correctly flush growing binlog file. · 10802c4d
      unknown authored
      When we append data to the binlog file, we use fdatasync() to ensure
      the data gets to disk so that crash recovery can work.
      
      Unfortunately there seems to be a bug in ext3/ext4 on linux, so that
      fdatasync() does not correctly sync all data when the size of a file
      is increased. This causes crash recovery to not work correctly (it
      loses transactions from the binlog).
      
      As a work-around, use fsync() for the binlog, not fdatasync(). Since
      we are increasing the file size, (correct) fdatasync() will most
      likely not be faster than fsync() on any file system, and fsync()
      does work correctly on ext3/ext4. This avoids the need to try to
      detect if we are running on buggy ext3/ext4.
      10802c4d
    • Sergei Golubchik's avatar
      MDEV-437 Microseconds: In time functions precision is calculated modulo 256 · 0536c506
      Sergei Golubchik authored
      store the precision in uint, not uint8
      0536c506