1. 27 Nov, 2009 4 commits
  2. 25 Nov, 2009 2 commits
    • Satya B's avatar
      Applying InnoDB snapshot 5.0-ss6230, part 2. Fixes BUG#46000 · 97d74332
      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.
      
      
      97d74332
    • Satya B's avatar
      Applying InnoDB snapshot 5.0-ss6230, Part 1. Fixes BUG#47777 · 2bf2e8f9
      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.
      
      
      2bf2e8f9
  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 · ed9e3409
      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.
      ed9e3409
  6. 17 Nov, 2009 2 commits
    • Kent Boortz's avatar
    • Alexey Kopytov's avatar
      Bug #48472: Loose index scan inappropriately chosen for some · 8cfa50e6
      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.
      
      mysql-test/r/group_min_max.result:
        Added a test case for bug #48472.
      mysql-test/t/group_min_max.test:
        Added a test case for bug #48472.
      sql/opt_range.cc:
        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.
      8cfa50e6
  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 · ddd90017
      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.
      ddd90017
  10. 06 Nov, 2009 2 commits
    • Alexey Kopytov's avatar
      Automerge. · 58ee6c80
      Alexey Kopytov authored
      58ee6c80
    • Alexey Kopytov's avatar
      Bug #48475: DISTINCT is ignored with GROUP BY WITH ROLLUP and · 39f9a3ff
      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.
      
      mysql-test/r/olap.result:
        Added a test case for bug #48475.
      mysql-test/t/olap.test:
        Added a test case for bug #48475.
      sql/sql_select.cc:
        Disabled const-only table optimizations for the WITH ROLLUP
        case.
      39f9a3ff
  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 · e29b7ef5
      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.
      e29b7ef5
    • Timothy Smith's avatar
      Bug#48086: mysql_secure_installation does NOT work on Solaris · d31e4636
      Timothy Smith authored
      Remove a bash-ism (if ! ...).
      d31e4636
    • Davi Arnaut's avatar
      69859d8d
    • Konstantin Osipov's avatar
      A fix and a test case for · 06c9d62a
      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.
      
      
      mysql-test/r/bug41756.result:
        Add result file (Bug#41756)
      mysql-test/t/bug41756-master.opt:
        Use --innodb-locks-unsafe-for-binlog, as in 5.0 just
        using read_committed isolation is not sufficient to 
        reproduce the bug.
      mysql-test/t/bug41756.test:
        Add a test file (Bug#41756)
      sql/item_subselect.cc:
        Complete struct READ_RECORD initialization with a new
        member to unlock records.
      sql/records.cc:
        Extend READ_RECORD API with a method to unlock read records.
      sql/sql_select.cc:
        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.
      sql/sql_select.h:
        Add members to TABLE_REF to count TABLE_REF buffer usage count.
      sql/structs.h:
        Update declarations.
      06c9d62a
    • unknown's avatar
      BUG#48216 Replication fails on all slaves after upgrade to 5.0.86 on master · 98198851
      unknown 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.
      
      
      98198851
  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 · 141e7961
      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.
      141e7961
    • Alexey Kopytov's avatar
      Automerge. · 7f965636
      Alexey Kopytov authored
      7f965636
    • Alexey Kopytov's avatar
      Bug #48131: crash group by with rollup, distinct, filesort, · b67cdaa3
      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.
      
      mysql-test/r/olap.result:
        Added a test case for bug #48131.
      mysql-test/t/olap.test:
        Added a test case for bug #48131.
      sql/sql_select.cc:
        1. Disabled inapplicable DISTINCT/GROUP BY optimizations when
        the WITH ROLLUP modifier is present.
        2. Split the const-wrapping part of JOIN::rollup_init() into a
        separate method.
      sql/sql_select.h:
        Added rollup_process_const_fields() declaration.
      b67cdaa3
    • Georgi Kodinov's avatar
      merge from 5.0-main · ecef6c33
      Georgi Kodinov authored
      ecef6c33
    • Georgi Kodinov's avatar
      Bug #48291 : crash with row() operator,select into @var, and · 9d96cd6d
      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.
      9d96cd6d
    • Georgi Kodinov's avatar
      Bug #48293: crash with procedure analyse, view with > 10 columns, · 851e2509
      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.
      851e2509
  15. 29 Oct, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #42116 : Mysql crash on specific query · ac373248
      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.
      
      mysql-test/r/join.result:
        Bug #42116: test case
      mysql-test/t/join.test:
        Bug #42116: test case
      sql/sql_select.cc:
        Bug #41116: don't go up and set the bits if more tables in
        at the current JOIN level
      ac373248
  16. 28 Oct, 2009 1 commit
  17. 27 Oct, 2009 1 commit