1. 24 Oct, 2007 1 commit
    • unknown's avatar
      BUG#31159 - fulltext search on ucs2 column crashes server · 660d6626
      unknown authored
      ucs2 doesn't provide required by fulltext ctype array. Crash
      happens because fulltext attempts to use unitialized ctype
      array.
      
      Fixed by converting ucs2 fields to compatible utf8 analogue.
      
      
      include/my_sys.h:
        Added a function to find compatible character set with ctype array
        available. Currently used by fulltext search to find compatible
        substitute for ucs2 collations.
      mysql-test/r/ctype_ucs.result:
        A test case for BUG#31159.
      mysql-test/t/ctype_ucs.test:
        A test case for BUG#31159.
      mysys/charset.c:
        Added a function to find compatible character set with ctype array
        available. Currently used by fulltext search to find compatible
        substitute for ucs2 collations.
      sql/item_func.cc:
        Convert ucs2 fields to utf8. Fulltext requires ctype array, but
        ucs2 doesn't provide it.
      660d6626
  2. 28 Sep, 2007 1 commit
  3. 14 Sep, 2007 2 commits
  4. 13 Sep, 2007 1 commit
    • unknown's avatar
      BUG#30590 - delete from memory table with composite btree primary key · cf5762b4
      unknown authored
      DELETE query against memory table with btree index may remove
      not all matching rows. This happens only when DELETE uses
      index read method to find matching rows. E.g. for queries
      like DELETE FROM t1 WHERE a=1.
      
      Fixed by reverting fix for BUG9719 and applying proper solution.
      
      
      heap/hp_delete.c:
        Reverted fix for BUG9719 as it makes queries like
        DELETE FROM t1 WHERE a=1 to remove not all matching
        rows (assuming this is memory table and there is btree
        key over `a`).
        
        This happens because we calculate info->lastkey_len in
        heap_rkey(). When we enter heap_rnext(), info->lastkey_len
        is 0 (set by hp_rb_delete_key()). We need to preserve
        info->lastkey_len in this situation, otherwise
        tree_search_key() will always return smallest value in
        a tree.
      heap/hp_rfirst.c:
        If we're performing index_first on a table that was taken from
        table cache, info->lastkey_len is initialized to previous query.
        Thus we set info->lastkey_len to proper value for subsequent
        heap_rnext() calls.
        This is needed for DELETE queries only, otherwise this variable is
        not used.
        Note that the same workaround may be needed for heap_rlast(), but
        for now heap_rlast() is never used for DELETE queries.
      heap/hp_rnext.c:
        An optimization for DELETE queries that use index_first()/index_next().
        Use faster tree_search_edge() instead of tree_search_key().
      mysql-test/r/heap_btree.result:
        A test case for BUG#30590.
      mysql-test/t/heap_btree.test:
        A test case for BUG#30590.
      cf5762b4
  5. 10 Sep, 2007 1 commit
  6. 04 Sep, 2007 1 commit
  7. 29 Aug, 2007 5 commits
    • unknown's avatar
      libmysql_r/client_settings.h libmysqld/ha_blackhole.cc · f3b2c398
      unknown authored
        Deleted BitKeeper soft links not needed
      
      
      BitKeeper/deleted/.del-client_settings.h:
        Delete: libmysql_r/client_settings.h
      BitKeeper/deleted/.del-ha_blackhole.cc:
        Delete: libmysqld/ha_blackhole.cc
      f3b2c398
    • unknown's avatar
      mysql_config.sh: · 16ce5d11
      unknown authored
        Flag changed name in icc 10
      
      
      scripts/mysql_config.sh:
        Flag changed name in icc 10
      16ce5d11
    • unknown's avatar
      Remove any old pidfile before starting mysqld to make sure that · 10012b36
      unknown authored
      'mysqld_wait_started' don't return prematurely because of an old
      pidfile
      
      
      10012b36
    • unknown's avatar
      Fix typo: '$$' => '$' · 305c3526
      unknown authored
      305c3526
    • unknown's avatar
      Add 'mtr_rmtree' · 038df2d0
      unknown authored
      
      mysql-test/lib/mtr_misc.pl:
        Add function 'mtr_rmtree' it will try 'rmtree' and if that fails (most likely
        due to permission problems we will fun File::find to chmod all files and dirs
        to 0777 and then delete.
      mysql-test/mysql-test-run.pl:
        Use 'mtr_rmtree' in favour of 'rmtree'
      038df2d0
  8. 13 Aug, 2007 1 commit
  9. 05 Aug, 2007 1 commit
  10. 04 Aug, 2007 1 commit
  11. 02 Aug, 2007 7 commits
  12. 01 Aug, 2007 3 commits
    • unknown's avatar
      Merge jperkin@bk-internal.mysql.com:/home/bk/mysql-4.1-maint · bb88e1ee
      unknown authored
      into  production.mysql.com:/usersnfs/jperkin/bk/mysql-4.1-maint
      
      
      bb88e1ee
    • unknown's avatar
      Option 6 tries to grant global privileges at the database level · c517fea5
      unknown authored
      which does not work.  Removing these attempted privileges makes
      this identical to option 5 so remove it completely.  The spirit
      of the program appears to be aimed at database privileges, so do
      not add another option for granting global privileges as it may
      be unexpected.  Fixes bug#14618 (same as previous patch, this
      time applied to -maint tree).
      
      
      scripts/mysql_setpermission.sh:
        Option 6 tries to apply global privileges at the database
        level which does not work - remove it.
      c517fea5
    • unknown's avatar
      Bug#29838 - myisam corruption using concurrent select ... and update · 4158e75d
      unknown authored
      When using concurrent insert with parallel index reads, it could
      happen that reading sessions found keys that pointed to records
      yet to be written to the data file. The result was a report of
      a corrupted table. But it was false alert.
      
      When inserting a record in a table with indexes, the keys are
      inserted into the indexes before the record is written to the data
      file. When the insert happens concurrently to selects, an
      index read can find a key that references the record that is not
      yet written to the data file. To avoid any access to such record,
      the select saves the current end of file position when it starts.
      Since concurrent inserts are always appended at end of the data
      file, the select can easily ignore any concurrently inserted record.
      
      The problem was that the ignore was only done for non-exact key
      searches (partial key or using >, >=, < or <=).
      
      The fix is to ignore concurrently inserted records also for
      exact key searches.
      
      No test case. Concurrent inserts cannot be tested with the test
      suite. Test cases are attached to the bug report.
      
      
      myisam/mi_rkey.c:
        Bug#29838 - myisam corruption using concurrent select ... and update
        Fixed mi_rkey() to always ignore records beyond saved eof.
      4158e75d
  13. 31 Jul, 2007 2 commits
    • unknown's avatar
      Merge mysql.com:/home/hf/work/029717/my41-29717 · 6b745cf6
      unknown authored
      into  mysql.com:/home/hf/work/29717/my41-29717
      
      
      sql/sql_select.cc:
        Auto merged
      6b745cf6
    • unknown's avatar
      Bug #29717 INSERT INTO SELECT inserts values even if · 791584ae
      unknown authored
       SELECT statement itself returns empty.
      
      As a result of this bug 'SELECT AGGREGATE_FUNCTION(fld) ... GROUP BY'
      can return one row instead of an empty result set.
      
      When GROUP BY only has fields of constant tables
      (with a single row), the optimizer deletes the group_list.
      After that we lose the information about whether we had an
      GROUP BY statement. Though it's important
      as SELECT min(x) from empty_table; and
         SELECT min(x) from empty_table GROUP BY y; have to return
      different results - the first query should return one row,
      second - an empty result set.
      So here we add the 'group_optimized_away' flag to remember this case
      when GROUP BY exists in the query and is removed
      by the optimizer, and check this flag in end_send_group()
      
      
      mysql-test/r/group_by.result:
        Bug #29717 INSERT INTO SELECT inserts values even if
         SELECT statement itself returns empty.
        
        test result
      mysql-test/r/insert_select.result:
        Bug #29717 INSERT INTO SELECT inserts values even if
         SELECT statement itself returns empty.
        
        test result
      mysql-test/t/group_by.test:
        Bug #29717 INSERT INTO SELECT inserts values even if
         SELECT statement itself returns empty.
        
        This is additional testcase that is more basic than the
        original bug's testcase and has the same reason.
      mysql-test/t/insert_select.test:
        Bug #29717 INSERT INTO SELECT inserts values even if
         SELECT statement itself returns empty.
        
        test case
      sql/sql_select.cc:
        Bug #29717 INSERT INTO SELECT inserts values even if
         SELECT statement itself returns empty.
        
        Remember the 'GROUP BY was optimized away' case in the JOIN::group_optimized
        and check this in the end_send_group()
      sql/sql_select.h:
        Bug #29717 INSERT INTO SELECT inserts values even if
         SELECT statement itself returns empty.
        
        JOIN::group_optimized member added to remember the 'GROUP BY optimied away'
        case
      791584ae
  14. 30 Jul, 2007 1 commit
    • unknown's avatar
      my_pthread.c: · 8d0526a8
      unknown authored
        Backport of correction for Mac OS X build problem, global variable not
        initiated is "common" and can't be used in shared libraries, unless
        special flags are used (bug#26218)
      
      
      mysys/my_pthread.c:
        Backport of correction for Mac OS X build problem, global variable not
        initiated is "common" and can't be used in shared libraries, unless
        special flags are used (bug#26218)
      8d0526a8
  15. 26 Jul, 2007 3 commits
    • unknown's avatar
      Merge dfischer@bk-internal.mysql.com:/home/bk/mysql-4.1 · eb79904d
      unknown authored
      into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-4.1
      
      
      eb79904d
    • unknown's avatar
      Merge debian.(none):/M41/bug16635-4.1 · 947e42af
      unknown authored
      into  debian.(none):/M41/push-4.1
      
      
      947e42af
    • unknown's avatar
      Raise the 64 character limit for path names in the error messages · 00d694a9
      unknown authored
      to 150 or 107 characters for those messages which are generated
      by the embedded server during release builds.
      
      This fixes bug#16635:
         Error messages wrong: absolute path names, "%s" format code
      
      See the bug report or the changelog for "sql/share/english/errmsg.txt"
      for instructions how to do that with other languages, 
      even at the customer site, and for the restrictions to keep.
      
      
      sql/share/english/errmsg.txt:
        The embedded server uses absolute path names in its error messages,
        in the release build environment these exceed the 64 character limit
        which the format strings for the error messages impose (bug#16635).
        
        But when the messages are output, the server does the "printf()" 
        internally in a 256 character buffer; the constant text and the
        expanded variables (strings, error number) must fit into this.
        
        (If the buffer would overflow, a format specification will not be
        expanded but just copied with its code, and the message output
        will just contain '%s' or '%d' where a value is expected.)
        
        So the string lengths are increased to 150 characters in those messages
        which are issued by the embedded server during release tests
        and contain 1 (one) path name,
        but only to 107 in the "rename" message which contains 2 (two).
        
        This solves bug#16635 for the release builds.
        
        For other languages used by OEM customers, similar fixes may be needed,
        but we cannot test them.
        
        These fixes can be done even in a binary installation at the customer site
        by following these steps:
           cd <<install-root>>/share
           $EDITOR <<lang>>/errmsg.txt
           ../../bin/comp_err -C./charsets/ <<lang>>/errmsg.txt <<lang>>/errmsg.sys
        and then restarting the server.
      00d694a9
  16. 22 Jul, 2007 1 commit
  17. 21 Jul, 2007 1 commit
    • unknown's avatar
      Fixed bug #29911. · 72c6c789
      unknown authored
      This bug manifested itself for join queries with GROUP BY and HAVING clauses
      whose SELECT lists contained DISTINCT. It occurred when the optimizer could
      deduce that the result set would have not more than one row.
      The bug could lead to wrong result sets for queries of this type because
      HAVING conditions were erroneously ignored in some cases in the function
      remove_duplicates.   
      
      
      mysql-test/r/having.result:
        Added a test case for bug #29911.
      mysql-test/t/having.test:
        Added a test case for bug #29911.
      72c6c789
  18. 20 Jul, 2007 2 commits
  19. 17 Jul, 2007 1 commit
  20. 16 Jul, 2007 1 commit
  21. 14 Jul, 2007 1 commit
  22. 13 Jul, 2007 1 commit
    • unknown's avatar
      Bug#27198: Error returns from time() are ignored · a7e5f73a
      unknown authored
      gettimeofday() can fail and presumably, so can time().
      Keep an eye on it.
      
      Since we have no data on this at all so far, we just
      retry on failure (and log the event), assuming that
      this is just an intermittant failure. This might of
      course hang the threat until we succeed. Once we know
      more about these failures, an appropriate more clever
      scheme may be picked (only try so many times per thread,
      etc., if that fails, return last "good" time() we got or
      some such).  Using sql_print_information() to log as this
      probably only occurs in high load scenarios where the debug-
      trace likely is disabled (or might interfere with testing
      the effect).  No test-case as this is a non-deterministic
      issue.
      
      
      sql/mysql_priv.h:
        Bug#27198: Error returns from time() are ignored
        
        move declarations for log.cc to before inclusion of
        sql_class.h as we now use sql_print_information() in
        there.
      sql/sql_class.h:
        Bug#27198: Error returns from time() are ignored
        
        gettimeofday() can fail and presumably, so can time().
        Keep an eye on it.
      a7e5f73a
  23. 12 Jul, 2007 1 commit