1. 30 Oct, 2009 2 commits
    • Alexey Kopytov's avatar
      Automerge. · b68ca5e8
      Alexey Kopytov authored
      b68ca5e8
    • Alexey Kopytov's avatar
      Bug #48131: crash group by with rollup, distinct, filesort, · 23b05d00
      Alexey Kopytov authored
                  with temporary tables
      
      There were two problems the test case from this bug was
      triggering:
      
      1. JOIN::rollup_init() was supposed to wrap all constant Items
      into another object for queries with the WITH ROLLUP modifier
      to ensure they are never considered as constants and therefore
      are written into temporary tables if the optimizer chooses to
      employ them for DISTINCT/GROUP BY handling.
      
      However, JOIN::rollup_init() was called before
      make_join_statistics(), so Items corresponding to fields in
      const tables could not be handled as intended, which was
      causing all kinds of problems later in the query execution. In
      particular, create_tmp_table() assumed all constant items
      except "hidden" ones to be removed earlier by remove_const()
      which led to improperly initialized Field objects for the
      temporary table being created. This is what was causing crashes
      and valgrind errors in storage engines.
      
      2. Even when the above problem had been fixed, the query from
      the test case produced incorrect results due to some
      DISTINCT/GROUP BY optimizations being performed by the
      optimizer that are inapplicable in the WITH ROLLUP case.
      
      Fixed by disabling inapplicable DISTINCT/GROUP BY optimizations
      when the WITH ROLLUP modifier is present, and splitting the
      const-wrapping part of JOIN::rollup_init() into a separate
      method which is now invoked after make_join_statistics() when
      the const tables are already known.
      23b05d00
  2. 19 Oct, 2009 5 commits
  3. 18 Oct, 2009 1 commit
    • Ramil Kalimullin's avatar
      Fix for bug#47963: Wrong results when index is used · df0b8e93
      Ramil Kalimullin authored
      Problem: using null microsecond part in a WHERE condition 
      (e.g. WHERE date_time_field <= "YYYY-MM-DD HH:MM:SS.0000") 
      may lead to wrong results due to improper DATETIMEs 
      comparison in some cases.
      
      Fix: comparing DATETIMEs as strings we must trim trailing 0's
      in such cases.
      df0b8e93
  4. 16 Oct, 2009 16 commits
  5. 15 Oct, 2009 8 commits
  6. 14 Oct, 2009 8 commits