1. 13 Jan, 2011 6 commits
  2. 12 Jan, 2011 2 commits
    • Bjorn Munch's avatar
      merge from 5.1-mtr · f23725f2
      Bjorn Munch authored
      f23725f2
    • Davi Arnaut's avatar
      Bug#42054: SELECT CURDATE() is returning bad value · 7bee52da
      Davi Arnaut authored
      The problem from a user point of view was that on Solaris the
      time related functions (e.g. NOW(), SYSDATE(), etc) would always
      return a fixed time.
      
      This bug was happening due to a logic in the time retrieving
      wrapper function which would only call the time() function every
      half second. This interval between calls would be calculated
      using the gethrtime() and the logic relied on the fact that time
      returned by it is monotonic.
      
      Unfortunately, due to bugs in the gethrtime() implementation,
      there are some cases where the time returned by it can drift
      (See Solaris bug id 6600939), potentially causing the interval
      calculation logic to fail.
      
      Since newer versions of Solaris (10+) have alleviated the
      performance degradation associated with time(2), the solution is
      to simply directly rely on time() at each invocation.
      
      This simplification has an upside that it allows us to eliminate
      a lock which was used to control access to the variables used
      to track the half second interval, thus improving the overall
      scalability of timekeeping related functions (e.g. NOW()).
      
      Benchmarks runs have shown no significant degradation associated
      with this change. With this, there are actually improvements in
      performance for cases involving many connections.
      
      In summary, the changes introduced by this patch are:
      
      a) my_time() and my_micro_time_and_time() no longer use gethrtime().
         Instead, time() and gettimeofdate() are used correspondingly.
      
      b) my_micro_time() is changed to not use gethrtime() so as to
         have the same time source as my_micro_time_and_time().
         There shouldn't be any performance impact from this change
         since this function is used only a few times during statement
         execution and, on Solaris, gettimeofday() shows acceptable
         performance.
      7bee52da
  3. 13 Jan, 2011 6 commits
    • Ole John Aske's avatar
      Fix for #58422: Incorrect result when OUTER JOIN'ing with an empty table. · 970c3fb2
      Ole John Aske authored
      Fixed incorrect checks in join_read_const_table() for when to 
      accept a non-existing, or empty const-row as a part of the const'ified 
      set of tables.
            
      Intention of this test is to only accept NULL-rows if this table is outer joined
      into the resultset. (In case of an inner-join we can conclude at this point that 
      resultset will be empty, end we want to return 'error' to signal this.)
            
      Initially 'maybe_null' is set to the same value as 'outer_join' in 
      setup_table_map(), mysql_priv.h ~line 2424. Later simplify_joins() will
      attemp to replace outer joins by inner join whenever possible. This
      will cause 'outer_join' to be updated. However, 'maybe_null' is *not* updated
      to reflect this rewrite as this field is used to currectly set the 'nullability'
      property for the columns in the resultset.
            
      We should therefore change join_read_const_table() to check the 'outer_join'
      property instead of 'maybe_null', as this correctly reflect the nullability of
      the *execution plan* (not *resultset*).
      970c3fb2
    • Nirbhay Choubey's avatar
      Merging from mysql-5.1. · e17c9279
      Nirbhay Choubey authored
      e17c9279
    • Ole John Aske's avatar
      Fix for bug#58134: 'Incorrectly condition pushdown inside subquery to NDB engine' · ba38eef6
      Ole John Aske authored
      An incorrect 'table_map' containing both the table itself, 
      and possible any outer-refs if this was the last table in 
      the subquery, was presented to make_cond_for_table().
            
      As a pushed condition is only able to refer column from the table
      the condition is pushed to, nothing else than columns from the
      table itself (tab->table->map) may be refered in the pushed condition
      constructed by 'push_cond= make_cond_for_table()'. 
            
      Also fix a minor 'copy and paste' bug in a comment 
      inside make_cond_for_table().
      
      No testcase is possible on mainbranch as the NDB engine is not available (yet)
      on mysql >= 5.5
      ba38eef6
    • Georgi Kodinov's avatar
      null merge of the version bumps. · ef331b0c
      Georgi Kodinov authored
      ef331b0c
    • Ole John Aske's avatar
      Fix for Bug#57034 incorrect OUTER JOIN result when joined on unique key · 3e1ce666
      Ole John Aske authored
      Item_equal::val_int() checked for NULL-values by checking Item::null_value
      *before* the respective ::store_value() and ::cmp(Item*) metods where called.
      
      As Item::null_value is set by these metods, the value of 'null_value' 
      is not valid until *after* ::store_value() or ::cmp() has
      been called for the Item object.
            
      Fix is to swap order of ::store_value()/::cmp() and checking of Item::null_value.
      This pattern is widely used other places inside item_cmpfunc.cc .
      3e1ce666
    • Martin Hansson's avatar
      Merge of fix for Bug#58165. · cecc99db
      Martin Hansson authored
      cecc99db
  4. 12 Jan, 2011 17 commits
    • Bjorn Munch's avatar
      null upmerge · 8c91dc62
      Bjorn Munch authored
      8c91dc62
    • Bjorn Munch's avatar
      merge from 5.5-mtr · 1dc4837a
      Bjorn Munch authored
      1dc4837a
    • Luis Soares's avatar
      BUG#59177: mysqlbinlog_row_big fails on Windows with out of memory · 51c6f8eb
      Luis Soares authored
            
      The test case fails with out of memory while updating a table
      with several multi-megabytes sized rows. This can probably be too
      exhausting for PB2 env.
            
      The quick fix here is to reduce the size of the biggest
      row (256MB) so that it becomes a little smaller (64MB).
      51c6f8eb
    • Evgeny Potemkin's avatar
      Auto-merge. · ce692c66
      Evgeny Potemkin authored
      ce692c66
    • Bjorn Munch's avatar
      null upmerge · 67224211
      Bjorn Munch authored
      67224211
    • Bjorn Munch's avatar
      merge from 5.5 main · d3c60fa6
      Bjorn Munch authored
      d3c60fa6
    • Bjorn Munch's avatar
      merge from 5.1 · 06c43adc
      Bjorn Munch authored
      06c43adc
    • Dmitry Lenev's avatar
      Merged fix for bug #58499 "DEFINER-security view selecting from · bc8e89c9
      Dmitry Lenev authored
      INVOKER-security view access check wrong" into mysql-5.5 tree.
      bc8e89c9
    • Bjorn Munch's avatar
      Bug #58841 Generalise handling of plugins in MTR mysql-test-run.pl script · add4385d
      Bjorn Munch authored
      Follow-up fix: mtr died if trying to run semisync test w/o the plugin
      add4385d
    • Alexey Botchkov's avatar
      merging. · 405fb864
      Alexey Botchkov authored
      405fb864
    • Dmitry Lenev's avatar
      Fix for bug #58499 "DEFINER-security view selecting from · 94fbedd3
      Dmitry Lenev authored
      INVOKER-security view access check wrong".
      
      When privilege checks were done for tables used from an 
      INVOKER-security view which in its turn was used from 
      a DEFINER-security view connection's active security
      context was incorrectly used instead of security context
      with privileges of the second view's creator.
      
      This meant that users which had enough rights to access
      the DEFINER-security view and as result were supposed to 
      be able successfully access it were unable to do so in 
      cases when they didn't have privileges on underlying tables 
      of the INVOKER-security view.
      
      This problem was caused by the fact that for INVOKER-security
      views TABLE_LIST::security_ctx member for underlying tables
      were set to 0 even in cases when particular view was used from 
      another DEFINER-security view. This meant that when checks of
      privileges on these underlying tables was done in
      setup_tables_and_check_access() active connection security 
      context was used instead of context corresponding to the 
      creator of caller view.
      
      This fix addresses the problem by ensuring that underlying
      tables of an INVOKER-security view inherit security context
      from the view and thus correct security context is used for
      privilege checks on underlying tables in cases when such view 
      is used from another view with DEFINER-security.
      94fbedd3
    • Alexey Botchkov's avatar
      Bug #57321 crashes and valgrind errors from spatial types · e073e2c0
      Alexey Botchkov authored
              Item_func_spatial_collection::fix_length_and_dec didn't call parent's method, so
              the maybe_null was set to '0' after it. But in this case the result was
              just NULL, that caused wrong behaviour.
      
      per-file comments:
        mysql-test/r/gis.result
      Bug #57321 crashes and valgrind errors from spatial types 
              test result updated.
      
        mysql-test/t/gis.test
      Bug #57321 crashes and valgrind errors from spatial types 
              test case added.
        sql/item_geofunc.h
      Bug #57321 crashes and valgrind errors from spatial types 
              Item_func_geometry::fix_length_and_dec() called in
              Item_func_spatial_collection::fix_length_and_dec().
      e073e2c0
    • Evgeny Potemkin's avatar
      Bug#59330: Incorrect result when comparing an aggregate function with · d6922c7e
      Evgeny Potemkin authored
      TIMESTAMP.
      
      Item_cache::get_cache wasn't treating TIMESTAMP as a DATETIME value thus
      returning string cache for items with TIMESTAMP type. This led to incorrect
      TIMESTAMP -> INT conversion and to a wrong query result.
      
      Fixed by using Item::is_datetime function to check for DATETIME type group.
      d6922c7e
    • Ole John Aske's avatar
      Fix for bug#58818: Incorrect result for IN/ANY subquery · 003e87fe
      Ole John Aske authored
      If the ::single_value_transformer() find an existing HAVING condition it used
      to do the transformation:
                  
        1) HAVING cond -> (HAVING Cond) AND (cond_guard (Item_ref_null_helper(...))
            
      As the AND condition in 1) is Mc'Carty evaluated, the
      right side of the AND cond should be executed only if the 
      original 'HAVING evaluated' to true.
            
      However, as we failed to set 'top_level' for the tranformed HAVING condition,
      'abort_on_null' was FALSE after transformation. An
      UNKNOWN having condition will then not terminate evaluation of the
      transformed having condition, and we incorrectly continued
      into the Item_ref_null_helper() part.
      003e87fe
    • Martin Hansson's avatar
      Merge of fix for Bug#58207. · b48abbc5
      Martin Hansson authored
      b48abbc5
    • Bjorn Munch's avatar
      Bug #59182 output of mysql-test-run.pl - mismatch between col names and actual col contents · a27de194
      Bjorn Munch authored
      New patch, avoid global $opt_parallel
      I still prefer not to print workerid when not doing parallel
      a27de194
    • Martin Hansson's avatar
      Bug#58207: invalid memory reads when using default column value and · fc42cbac
      Martin Hansson authored
      tmptable needed
      
      The function DEFAULT() works by modifying the the data buffer pointers (often
      referred to as 'record' or 'table record') of its argument. This modification
      is done during name resolution (fix_fields().) Unfortunately, the same
      modification is done when creating a temporary table, because default values
      need to propagate to the new table.
      
      Fixed by skipping the pointer modification for fields that are arguments to
      the DEFAULT function.
      fc42cbac
  5. 11 Jan, 2011 9 commits