1. 02 Nov, 2009 3 commits
    • Martin Hansson's avatar
      Bug#47925: regression of range optimizer and date comparison in 5.1.39! · f539e0c8
      Martin Hansson authored
      When a query was using a DATE or DATETIME value formatted
      using any other separator characters beside hyphen '-', a
      query with a greater-or-equal '>=' condition matching only
      the greatest value in an indexed column, the result was
      empty if index range scan was employed.
      
      The range optimizer got a new feature between 5.1.38 and
      5.1.39 that changes a greater-or-equal condition to a
      greater-than if the value matching that in the query was not
      present in the table. But the value comparison function
      compared the dates as strings instead of dates.
      
      The bug was fixed by splitting the function
      get_date_from_str in two: One part that parses and does
      error checking. This function is now visible outside the
      module. The old get_date_from_str now calls the new
      function.
      f539e0c8
    • Davi Arnaut's avatar
      Automerge. · bcf28194
      Davi Arnaut authored
      bcf28194
    • Tatiana A. Nurnberg's avatar
      auto-merge · 25a73325
      Tatiana A. Nurnberg authored
      25a73325
  2. 01 Nov, 2009 1 commit
  3. 31 Oct, 2009 1 commit
  4. 30 Oct, 2009 12 commits
    • Alexey Kopytov's avatar
      Automerge. · 445904a3
      Alexey Kopytov authored
      445904a3
    • Alexey Kopytov's avatar
      Automerge. · 695a6d41
      Alexey Kopytov authored
      695a6d41
    • Alexey Kopytov's avatar
      Automerge. · 406e680b
      Alexey Kopytov authored
      406e680b
    • 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
    • Georgi Kodinov's avatar
      merge · 04af81d7
      Georgi Kodinov authored
      04af81d7
    • Georgi Kodinov's avatar
      merge from 5.0-main · ea412fc2
      Georgi Kodinov authored
      ea412fc2
    • Georgi Kodinov's avatar
      merge · a765de73
      Georgi Kodinov authored
      a765de73
    • Georgi Kodinov's avatar
      Bug #48291 : crash with row() operator,select into @var, and · a0bea5ee
      Georgi Kodinov authored
        subquery returning multiple rows
      
      Error handling was missing when handling subqueires in WHERE 
      and when assigning a SELECT result to a @variable.
      This caused crash(es). 
      
      Fixed by adding error handling code to both the WHERE 
      condition evaluation and to assignment to an @variable.
      a0bea5ee
    • Georgi Kodinov's avatar
      merge · e8c608fe
      Georgi Kodinov authored
      e8c608fe
    • Georgi Kodinov's avatar
      Bug #48293: crash with procedure analyse, view with > 10 columns, · 7ba875d6
      Georgi Kodinov authored
      having clause...
      
      The fix for bug 46184 was not very complete. It was not covering
      views using temporary tables and multiple tables in a FROM clause.
      Fixed by reverting the fix for 46184 and making a more general
      check that is checking at the right execution stage and for all
      of the non-supported cases.
      Now PROCEDURE ANALYZE on non-top level SELECT is also forbidden.
      Updated the analyse.test and subselect.test accordingly.
      7ba875d6
    • Georgi Kodinov's avatar
      merge · 0dea5a63
      Georgi Kodinov authored
      0dea5a63
  5. 29 Oct, 2009 3 commits
    • Tatiana A. Nurnberg's avatar
      Bug#48295: explain extended crash with subquery and ONLY_FULL_GROUP_BY sql_mode · d7e7765b
      Tatiana A. Nurnberg authored
      If an outer query is broken, a subquery might not even get set up.
      EXPLAIN EXTENDED did not expect this and merrily tried to de-ref all
      of the half-setup info.
      
      We now catch this case and print as much as we have, as it doesn't cost us
      anything (doesn't make regular execution slower).
      d7e7765b
    • Georgi Kodinov's avatar
      Bug #42116 : Mysql crash on specific query · 1d8cceae
      Georgi Kodinov authored
      Queries with nested outer joins may lead to crashes or 
      bad results because an internal data structure is not handled
      correctly.
      The optimizer uses bitmaps of nested JOINs to determine
      if certain table can be placed at a certain place in the
      JOIN order.
      It does maintain a bitmap describing in which JOINs 
      last placed table is nested.
      When it puts a table it makes sure the bit of every JOIN that
      contains the table in question is set (because JOINs can be nested).
      It does that by recursively setting the bit for the next enclosing
      JOIN when this is the first table in the JOIN and recursively 
      resetting the bit if it's the last table in the JOIN.
      When it removes a table from the join order it should do the
      opposite : recursively unset the bit if it's the only remaining 
      table in this join and and recursively set the bit if it's removing
      the last table of a JOIN.
      There was an error in how the bits was set for the upper levels :
      when removing a table it was setting the bit for all the enclosing 
      nested JOINs even if there were more tables left in the current JOIN
      (which practically means that the upper nested JOINs were not affected).
      Fixed by stopping the recursion at the relevant level.
      1d8cceae
    • 's avatar
      Bug #46828 rpl_get_master_version_and_clock fails on PB-2 · fccc33a3
      authored
      The 'rpl_get_master_version_and_clock' test verifies if the slave I/O 
      thread tries to reconnect to master when it tries to get the values of 
      the UNIX_TIMESTAMP, SERVER_ID from master under network disconnection. 
      So the master server is restarted for making the transient network 
      disconnection. Restarting master server can bring two problems as following:
      
      1. The time out error is encountered sporadically. The slave I/O thread tries 
         to reconnect master ten times, which is set in my.cnf. So in the test 
         framework sporadically the slave I/O thread really stoped when it can't 
         reconnect to master in the ten times successfully before the master starts, 
         then the time out error will be encountered while waiting for the slave to 
         start.
      
      2. These warnings and errors are produced in server log file when 
         the slave I/O thread tries to get the values of the UNIX_TIMESTAMP, 
         SERVER_ID from master under the transient network disconnection.
      
      To fix problem 1, increase the master retry count to sixty times, 
      so that the slave I/O thread has enough time to reconnect master 
      successfully.
      To fix problem 2, suppress these warnings and errors by mtr suppression, 
      because they are expected.
      fccc33a3
  6. 28 Oct, 2009 5 commits
    • Sergey Vojtovich's avatar
      BUG#43171 - Assertion failed: thd->transaction.xid_state.xid.is_null() · d6f27e58
      Sergey Vojtovich authored
      XA START may cause assertion failure/server crash when it is called
      after unilateral roll back issued by the Resource Manager (both
      in regular transaction and after XA transaction).
      
      The problem was that rm_error variable wasn't set/reset properly.
      d6f27e58
    • Konstantin Osipov's avatar
      A patch and a test case for · fdcf0aff
      Konstantin Osipov authored
      Bug#46539 Various crashes on INSERT IGNORE SELECT + SELECT FOR UPDATE.
      
      If a transaction was rolled back inside InnoDB due to a deadlock
      or lock wait timeout, and the statement had IGNORE clause,
      the server could crash at the end of the statement or on shutdown.
      
      This was caused by the error handling infrastructure's attempt to 
      ignore a non-ignorable error.
      
      When a transaction rollback request is raised, switch off 
      current_select->no_error flag, so that the following error
      won't be ignored.
      
      Instead, we could add !thd->is_fatal_sub_stmt_error to
      my_message_sql(), but since in write_record() we switch
      off no_error, the same approach is used in 
      thd_mark_transaction_to_rollback().
      
      @todo: call thd_mark_transaction_to_rollback() from 
      handler::print_error(), then we can easily make sure
      that the error reported by print_error is not ignored.
      fdcf0aff
    • Sergey Glukhov's avatar
      5.0-bugteam->5.1-bugteam merge · 384bbf11
      Sergey Glukhov authored
      384bbf11
    • Sergey Glukhov's avatar
      Bug#41049 does syntax "grant" case insensitive? · c1a298d0
      Sergey Glukhov authored
      test result fix
      c1a298d0
    • 's avatar
      Bug #34777 mysqlbinlog: --help output for --base64-output is hard to understand · 6bd4cfe0
      authored
      Append the description of the 'decode-rows' value for --base64-output argument.
      6bd4cfe0
  7. 27 Oct, 2009 14 commits
    • Sergey Vojtovich's avatar
      Merge 5.1-bugteam -> 5.1-bugteam-local. · c23f7562
      Sergey Vojtovich authored
      c23f7562
    • Sergey Vojtovich's avatar
      A follow-up to fix for · 9fbc44eb
      Sergey Vojtovich authored
      BUG#47073 - valgrind errs, corruption,failed repair of partition,
                  low myisam_sort_buffer_size
      
      Fixed race conditions discovered with the provided test case and
      stabilized test case.
      9fbc44eb
    • Tatiana A. Nurnberg's avatar
      auto-merge · 5c7f01a0
      Tatiana A. Nurnberg authored
      5c7f01a0
    • Georgi Kodinov's avatar
      merge · b9553d83
      Georgi Kodinov authored
      b9553d83
    • Tatiana A. Nurnberg's avatar
      Bug#46586: When using the plugin interface the type "set" for options caused a crash. · 2f069a2c
      Tatiana A. Nurnberg authored
      "What do you mean, there's a bug? There isn't even code!"
      
      There was some token code for plug-in variables of the SET type,
      but clearly this never worked, or was subject to massive bit rot
      since. Bug-fixes ... fail-safes ... tests -- fais au mieux, mon chou!
      2f069a2c
    • Georgi Kodinov's avatar
      merge from 4.1 · 95dce2b0
      Georgi Kodinov authored
      95dce2b0
    • Sergey Glukhov's avatar
      null merge · 87adf6ff
      Sergey Glukhov authored
      87adf6ff
    • Sergey Glukhov's avatar
      automerge · fa63ac11
      Sergey Glukhov authored
      fa63ac11
    • Sergey Glukhov's avatar
      automerge · 80b79bae
      Sergey Glukhov authored
      80b79bae
    • Sergey Glukhov's avatar
      5.0-bugteam->5.1-bugteam merge · 1968895e
      Sergey Glukhov authored
      1968895e
    • Tatiana A. Nurnberg's avatar
      auto-merge · 842039a1
      Tatiana A. Nurnberg authored
      842039a1
    • Sergey Vojtovich's avatar
      df1fe9ee
    • Sergey Vojtovich's avatar
      An addition to fix for · cf41b43b
      Sergey Vojtovich authored
      BUG#41597 - After rename of user, there are additional grants
                  when grants are reapplied.
      
      Fixed build failure on Windows. Added missing cast.
      cf41b43b
    • Sergey Glukhov's avatar
      Bug#41049 does syntax "grant" case insensitive? · 58b7761e
      Sergey Glukhov authored
      Problem 1:
      column_priv_hash uses utf8_general_ci collation
      for the key comparison. The key consists of user name,
      db name and table name. Thus user with privileges on table t1
      is able to perform the same operation on T1
      (the similar situation with user name & db name, see acl_cache).
      So collation which is used for column_priv_hash and acl_cache
      should be case sensitive.
      The fix:
      replace system_charset_info with my_charset_utf8_bin for
      column_priv_hash and acl_cache
      Problem 2:
      The same situation with proc_priv_hash, func_priv_hash,
      the only difference is that Routine name is case insensitive.
      So the fix is to use my_charset_utf8_bin for
      proc_priv_hash & func_priv_hash and convert routine name into lower
      case before writing the element into the hash and
      before looking up the key.
      Additional fix: mysql.procs_priv Routine_name field collation
      is changed to utf8_general_ci.
      It's necessary for REVOKE command
      (to find a field by routine hash element values).
      Note: 
      It's safe for lower-case-table-names mode too because
      db name & table name are converted into lower case
      (see GRANT_NAME::GRANT_NAME).
      58b7761e
  8. 26 Oct, 2009 1 commit