1. 02 Aug, 2007 2 commits
  2. 01 Aug, 2007 2 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
  3. 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
  4. 26 Jul, 2007 2 commits
    • 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
  5. 22 Jul, 2007 1 commit
  6. 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
  7. 20 Jul, 2007 1 commit
    • unknown's avatar
      Bug #29494 Field packet with NULL fields crashes libmysqlclient. · 1a2d2117
      unknown authored
      unpack_fields() didn't expect NULL_LENGHT in the field's descriptions.
      In this case we get NULL in the resulting string so cannot use
      strdup_root to make a copy of it.
      strdup_root changed with strmake_root as it's NULL-safe
      
      
      sql-common/client.c:
        Bug #29494 Field packet with NULL fields crashes libmysqlclient
        
        strdup_root changed with strmake_root in unpack_fields()
      1a2d2117
  8. 17 Jul, 2007 1 commit
  9. 16 Jul, 2007 1 commit
  10. 14 Jul, 2007 1 commit
  11. 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
  12. 09 Jul, 2007 1 commit
  13. 08 Jul, 2007 2 commits
  14. 07 Jul, 2007 1 commit
  15. 06 Jul, 2007 2 commits
  16. 05 Jul, 2007 2 commits
    • unknown's avatar
      Merge chilla.local:/home/mydev/mysql-4.1-ateam · 01554dd9
      unknown authored
      into  chilla.local:/home/mydev/mysql-4.1-axmrg
      
      
      01554dd9
    • unknown's avatar
      BUG#27564 - Valgrind: UDF does not cleanup correctly · b7bf9725
      unknown authored
      Dropping an user defined function may cause server crash in
      case this function is still in use by another thread.
      
      The problem was that our hash implementation didn't update
      hash link list properly when hash_update() was called.
      
      
      mysys/hash.c:
        The following requirement wasn't met by hash_update() function
        causing corruption of hash links list:
        
        After a record was unlinked from the old chain during update, it
        holds random position. By the chance this position is equal to
        position for the first element in the new chain. That means
        updated record is the only record in the new chain.
      b7bf9725
  17. 04 Jul, 2007 1 commit
  18. 03 Jul, 2007 4 commits
    • unknown's avatar
      Merge gshchepa@bk-internal.mysql.com:/home/bk/mysql-4.1-opt · f57e4b99
      unknown authored
      into  gleb.loc:/home/uchum/work/bk/4.1-opt
      
      
      f57e4b99
    • unknown's avatar
      loaddata.result, loaddata.test: · bc3e0086
      unknown authored
        Test case update for bug #29294.
      
      
      mysql-test/t/loaddata.test:
        Test case update for bug #29294.
      mysql-test/r/loaddata.result:
        Test case update for bug #29294.
      bc3e0086
    • unknown's avatar
      sql_class.cc: · 19a5d20c
      unknown authored
        Windows compilation error fix.
      
      
      sql/sql_class.cc:
        Windows compilation error fix.
      19a5d20c
    • unknown's avatar
      Fixed bug #29294. · 166d3c91
      unknown authored
      The `SELECT 'r' INTO OUTFILE ... FIELDS ENCLOSED BY 'r' ' statement
      encoded the 'r' string to a 4 byte string of value x'725c7272'
      (sequence of 4 characters: r\rr).
      The LOAD DATA statement decoded this string to a 1 byte string of
      value x'0d' (ASCII Carriage Return character) instead of the original
      'r' character.
      The same error also happened with the FIELDS ENCLOSED BY clause
      followed by special characters: 'n', 't', 'r', 'b', '0', 'Z' and 'N'.
      
      NOTE 1: This is a result of the undocumented feature: the LOAD DATA INFILE
      recognises 2-byte input sequences like \n, \t, \r and \Z in addition
      to documented 2-byte sequences: \0 and \N. This feature should be
      documented (here backspace character is a default ESCAPED BY character,
      in the real-life example it may be any ESCAPED BY character).
      
      NOTE 2, changed behaviour:
      Now the `SELECT INTO OUTFILE' statement with the `FIELDS ENCLOSED BY'
      clause followed by one of: 'n', 't', 'r', 'b', '0', 'Z' or 'N' characters
      encodes this special character itself by doubling it ('r' --> 'rr'),
      not by prepending it with an escape character.
      
      
      sql/sql_class.h:
        Fixed bug #29294.
        The ESCAPE_CHARS macro constant is defined to enumerate
        symbolic names of espace-sequences like  '\n', '\t' etc.
        The select_export::is_ambiguous_field_sep field has been added
        to distinguish special values of the field_sep field from
        another values (see ESCAPE_CHARS).
      sql/sql_class.cc:
        Fixed bug #29294.
        The select_export::send_data method has been modified to
        encode special values of the field_sep field by
        doubling of those values instead of prepending them with a
        value of the escape_char field.
        Example: The SELECT 'r' INTO OUTFILE FIELDS ENCLOSED BY 'r'
        now produces the 'rr' output string instead of x'5c72'
        (i.e. instead of sequence of 2 bytes: \ and r).
      sql/sql_load.cc:
        Fixed bug #29294.
        Added commentary for the READ_INFO::unescape method.
      mysql-test/t/loaddata.test:
        Updated test case for bug #29294.
      mysql-test/r/loaddata.result:
        Updated test case for bug #29294.
      166d3c91
  19. 26 Jun, 2007 2 commits
    • unknown's avatar
      Fixed bug #29251. · 7fbf6303
      unknown authored
      Sometimes special 0 ENUM values was ALTERed to normal
      empty string ENUM values.
      
      Special 0 ENUM value has the same string representation
      as normal ENUM value defined as '' (empty string).
      The do_field_string function was used to convert
      ENUM data at an ALTER TABLE request, but this
      function doesn't care about numerical "indices" of
      ENUM values, i.e. do_field_string doesn't distinguish
      a special 0 value from an empty string value.
      
      A new copy function called do_field_enum has been added to
      copy special 0 ENUM values without conversion to an empty
      string.
      
      
      sql/field_conv.cc:
        Fixed bug #29251.
        The Copy_field::get_copy_func method has been modified to
        return a pointer to the do_field_enum function if a conversion
        between two columns of incompatible enum types is required.
        The do_field_enum function has been added for the correct
        conversion of special 0 enum values.
      mysql-test/t/type_enum.test:
        Updated test case for bug #29251.
      mysql-test/r/type_enum.result:
        Updated test case for bug #29251.
      7fbf6303
    • unknown's avatar
      Merge maint1.mysql.com:/data/localhome/tsmith/bk/41 · 58419e9e
      unknown authored
      into  maint1.mysql.com:/data/localhome/tsmith/bk/maint/41
      
      
      58419e9e
  20. 25 Jun, 2007 1 commit
  21. 23 Jun, 2007 1 commit
  22. 22 Jun, 2007 1 commit
    • unknown's avatar
      Fix for bug #29079: Semantics of "bigint" depend on platform specifics (size, signedness of char ?) · ae587cfb
      unknown authored
      Problem: long and long long types mess in a comparison may lead to wrong results on some platforms.
      Fix: prefer [unsigned] long long as [u]longlong as it's used unconditionally in many places.
      
      
      include/my_global.h:
        Fix for bug #29079: Semantics of "bigint" depend on platform specifics (size, signedness of char ?)
          - use [unsigned] long long as [u]longlong if sizeof(long long) == 8, to avoid type mess,
            as we use [unsigned] long long unconditionally in many places, for example in constants 
            with [U]LL suffix.
      ae587cfb
  23. 20 Jun, 2007 1 commit
  24. 19 Jun, 2007 4 commits
  25. 18 Jun, 2007 3 commits