1. 18 Jan, 2011 2 commits
  2. 17 Jan, 2011 7 commits
  3. 16 Jan, 2011 1 commit
  4. 15 Jan, 2011 5 commits
    • Nirbhay Choubey's avatar
    • Nirbhay Choubey's avatar
      Bug#58221 : mysqladmin --sleep=x --count=x keeps looping · 44d23cdb
      Nirbhay Choubey authored
      When mysqldadmin is run with sleep and count options,
      it goes into an infinite loop and keeps executing the
      specified command.
      
      This happened because the statement, responsible for
      decrementing the count value, was missing.
      
      Fixed by adding a statement which will decrement the
      count value for each iteration.
      44d23cdb
    • 's avatar
      Auto merge · 3533c1d3
      authored
      3533c1d3
    • 's avatar
      Null merge from 5.0 · 38277835
      authored
      It is a backported patch.
      38277835
    • 's avatar
      BUG#49124 Security issue with /*!-versioned */ SQL statements on Slave · ade1c74b
      authored
      Backport to 5.0.
      
      /*![:version:] Query Code */, where [:version:] is a sequence of 5 
      digits representing the mysql server version(e.g /*!50200 ... */),
      is a special comment that the query in it can be executed on those 
      servers whose versions are larger than the version appearing in the 
      comment. It leads to a security issue when slave's version is larger 
      than master's. A malicious user can improve his privileges on slaves. 
      Because slave SQL thread is running with SUPER privileges, so it can
      execute queries that he/she does not have privileges on master.
            
      This bug is fixed with the logic below: 
      - To replace '!' with ' ' in the magic comments which are not applied on
        master. So they become common comments and will not be applied on slave.
            
      - Example:
        'INSERT INTO t1 VALUES (1) /*!10000, (2)*/ /*!99999 ,(3)*/
         will be binlogged as
        'INSERT INTO t1 VALUES (1) /*!10000, (2)*/ /* 99999 ,(3)*/
      ade1c74b
  5. 14 Jan, 2011 13 commits
  6. 13 Jan, 2011 9 commits
  7. 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
  8. 13 Jan, 2011 1 commit
    • 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