1. 27 Nov, 2009 1 commit
  2. 25 Nov, 2009 2 commits
    • Satya B's avatar
      Applying InnoDB snapshot 5.0-ss6230, part 2. Fixes BUG#46000 · e2afa05e
      Satya B authored
      BUG#46000 - using index called GEN_CLUST_INDEX crashes server
      
      Detailed revision comments:
      
      r6180 | jyang | 2009-11-17 10:54:57 +0200 (Tue, 17 Nov 2009) | 7 lines
      branches/5.0: Merge/Port fix for bug #46000 from branches/5.1
      -r5895 to branches/5.0. Disallow creating index with the
      name of "GEN_CLUST_INDEX" which is reserved for the default
      system primary index. Minor adjusts on table name screening
      format for added tests.
      
      e2afa05e
    • Satya B's avatar
      Applying InnoDB snapshot 5.0-ss6230, Part 1. Fixes BUG#47777 · 0dd5eaa5
      Satya B authored
      BUG#47777 - innodb dies with spatial pk: Failing assertion: buf <= original_buf + buf_len
      
      Detailed revision comments:
      
      r6178 | jyang | 2009-11-17 08:52:11 +0200 (Tue, 17 Nov 2009) | 6 lines
      branches/5.0: Merge fix for bug #47777 from branches/5.1 -r6045
      to bracnches/5.0. Treat the Geometry data same as Binary BLOB
      in ha_innobase::store_key_val_for_row(), since the Geometry
      data is stored as Binary BLOB in Innodb.
      
      0dd5eaa5
  3. 23 Nov, 2009 2 commits
  4. 20 Nov, 2009 1 commit
  5. 18 Nov, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug#48864: MySQL fails to compile on 64 bit Fedora 12 · 6b3b2c0c
      Georgi Kodinov authored
      Fixed 2 errors in comp_err executable : 
      1. Wrong (off by 1) length passed to my_checksum()
      2. strmov() was used on overlapping strings. This is
       not legal according to the docs in stpcpy(). Used 
      the overlap safe memmove() instead.
      6b3b2c0c
  6. 17 Nov, 2009 2 commits
    • Kent Boortz's avatar
    • Alexey Kopytov's avatar
      Bug #48472: Loose index scan inappropriately chosen for some · 7f2ba28e
      Alexey Kopytov authored
                  WHERE conditions 
       
      check_group_min_max() checks if the loose index scan 
      optimization is applicable for a given WHERE condition, that is 
      if the MIN/MAX attribute participates only in range predicates 
      comparing the corresponding field with constants. 
       
      The problem was that it considered the whole predicate suitable 
      for the loose index scan optimization as soon as it encountered 
      a constant as a predicate argument. This is obviously wrong for 
      cases when a constant is the first argument of a predicate 
      which does not satisfy the above condition. 
       
      Fixed check_group_min_max() so that all arguments of the input 
      predicate are considered to decide if it passes the test, even 
      though a constant has already been encountered.
      7f2ba28e
  7. 12 Nov, 2009 2 commits
  8. 09 Nov, 2009 2 commits
  9. 10 Nov, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #42760: Select doesn't return desired results when we have null · 154c3480
      Georgi Kodinov authored
       values
       
       We should re-set the access method functions when changing the access
       method when switching to another index to avoid sorting.
       
       Fixed by doing a little re-engineering : encapsulating all the function
       assignment into a special function and calling it when flipping the 
       indexes.
      154c3480
  10. 06 Nov, 2009 2 commits
    • Alexey Kopytov's avatar
      Automerge. · 5d725601
      Alexey Kopytov authored
      5d725601
    • Alexey Kopytov's avatar
      Bug #48475: DISTINCT is ignored with GROUP BY WITH ROLLUP and · 9fff9acf
      Alexey Kopytov authored
                  only const tables
      
      The problem was caused by two shortcuts in the optimizer that
      are inapplicable in the ROLLUP case.
      
      Normally in a case when only const tables are involved in a
      query, DISTINCT clause can be safely optimized away since there
      may be only one row produced by the join. Similarly, we don't
      need to create a temporary table to resolve DISTINCT/GROUP
      BY/ORDER BY. Both of these are inapplicable when the WITH
      ROLLUP modifier is present.
      
      Fixed by disabling the said optimizations for the WITH ROLLUP
      case.
      9fff9acf
  11. 04 Nov, 2009 5 commits
  12. 03 Nov, 2009 6 commits
    • Timothy Smith's avatar
    • Timothy Smith's avatar
      Bug#48031: mysql_secure_installation -- bash bug regarding passwords with · 3aff1e95
      Timothy Smith authored
        special chars
      
      This script failed when the user tried passwords with multiple spaces, \, # or
      ' characters.  Now proper escaping and quoting is used in all contexts.
      
      This problem occurs in the Perl version of this script, too, so fix it in both
      places.
      3aff1e95
    • Timothy Smith's avatar
      Bug#48086: mysql_secure_installation does NOT work on Solaris · 9e7cd0fb
      Timothy Smith authored
      Remove a bash-ism (if ! ...).
      9e7cd0fb
    • Davi Arnaut's avatar
      fc55339e
    • Konstantin Osipov's avatar
      A fix and a test case for · d2babeaf
      Konstantin Osipov authored
      Bug#41756 "Strange error messages about locks from InnoDB".
      
      In JT_EQ_REF (join_read_key()) access method,
      don't try to unlock rows in the handler, unless certain that
      a) they were locked
      b) they are not used.
      
      Unlocking of rows is done by the logic of the nested join loop,
      and is unaware of the possible caching that the access method may
      have. This could lead to double unlocking, when a row
      was unlocked first after reading into the cache, and then
      when taken from cache, as well as to unlocking of rows which
      were actually used (but taken from cache).
      
      Delegate part of the unlocking logic to the access method,
      and in JT_EQ_REF count how many times a record was actually
      used in the join. Unlock it only if it's usage count is 0.
      
      Implemented review comments.
      d2babeaf
    • 's avatar
      BUG#48216 Replication fails on all slaves after upgrade to 5.0.86 on master · 133bfc7f
      authored
      When a sessione is closed, all temporary tables of the session are automatically 
      dropped and are binlogged. But it will be binlogged with wrong database names when
      the length of the temporary tables' database names are greater than the 
      length of the current database name or the current database is not set.
      
      Query_log_event's db_len is forgot to set when Query_log_event's db is set.
      This patch wrote code to set db_len immediately after db has set.
      
      133bfc7f
  13. 02 Nov, 2009 1 commit
  14. 30 Oct, 2009 6 commits
    • Timothy Smith's avatar
      Bug#35106: mysql_secure_installation fails on Windows, missing "use · 61973d67
      Timothy Smith authored
      Term::ReadKey"
      
      Add the missing module import.  Also, while here, fix a few glaring problems
      with the script, and ensure that it behaves properly.  It seems this script
      may have never been working correctly (e.g., reading password didn't chomp()
      the result, so password was set with \n at the end; comparing the re-typed
      password to original was done with inverted test).
      
      Add END { cleanup(); } block to ensure the script removes temporary working
      files.
      
      Add SIG{INT} / SIG{QUIT} handler.
      
      Do a bit of reorganization to make the code easier to understand.
      
      Limit failed connection attempts to 3.
      
      Use ./bin/mysql if it exists, and then fall back on mysql in PATH (before it
      assumed 'mysql' in the path).  Print a nicer error if 'mysql' can't be called.
      
      This has been tested on Windows (ActivePerl from cmd.exe, no cygwin needed)
      and Linux.
      61973d67
    • Alexey Kopytov's avatar
      Automerge. · 406e680b
      Alexey Kopytov authored
      406e680b
    • 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 from 5.0-main · ea412fc2
      Georgi Kodinov authored
      ea412fc2
    • 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
      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
  15. 29 Oct, 2009 1 commit
    • 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
  16. 28 Oct, 2009 1 commit
  17. 27 Oct, 2009 4 commits
    • Georgi Kodinov's avatar
      merge from 4.1 · 95dce2b0
      Georgi Kodinov authored
      95dce2b0
    • Sergey Glukhov's avatar
      automerge · 80b79bae
      Sergey Glukhov authored
      80b79bae
    • 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