- 02 Aug, 2007 2 commits
- 30 Jul, 2007 1 commit
-
-
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)
-
- 26 Jul, 2007 2 commits
-
-
unknown authored
into debian.(none):/M41/push-4.1
-
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.
-
- 22 Jul, 2007 1 commit
-
-
unknown authored
into mysql.com:/home/hf/work/29494/my41-29494
-
- 21 Jul, 2007 1 commit
-
-
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.
-
- 20 Jul, 2007 1 commit
-
-
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()
-
- 17 Jul, 2007 1 commit
-
-
unknown authored
into ramayana.hindu.god:/home/tsmith/m/bk/maint/41
-
- 16 Jul, 2007 1 commit
-
-
unknown authored
into sin.intern.azundris.com:/home/tnurnberg/27198/41-27198 sql/mysql_priv.h: Bug #27198: Error returns from time() are ignored manual merge sql/sql_class.h: Bug #27198: Error returns from time() are ignored manual merge
-
- 14 Jul, 2007 1 commit
-
-
unknown authored
into chilla.local:/home/mydev/mysql-4.1-axmrg
-
- 13 Jul, 2007 1 commit
-
-
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.
-
- 09 Jul, 2007 1 commit
-
-
unknown authored
into sita.local:/Users/tsmith/m/bk/maint/41
-
- 08 Jul, 2007 2 commits
- 07 Jul, 2007 1 commit
-
-
unknown authored
into gleb.loc:/home/uchum/work/bk/4.1-opt
-
- 06 Jul, 2007 2 commits
- 05 Jul, 2007 2 commits
-
-
unknown authored
into chilla.local:/home/mydev/mysql-4.1-axmrg
-
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.
-
- 04 Jul, 2007 1 commit
-
-
unknown authored
into maint1.mysql.com:/data/localhome/tsmith/bk/maint/41
-
- 03 Jul, 2007 4 commits
-
-
unknown authored
into gleb.loc:/home/uchum/work/bk/4.1-opt
-
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.
-
unknown authored
Windows compilation error fix. sql/sql_class.cc: Windows compilation error fix.
-
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.
-
- 26 Jun, 2007 2 commits
-
-
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.
-
unknown authored
into maint1.mysql.com:/data/localhome/tsmith/bk/maint/41
-
- 25 Jun, 2007 1 commit
-
-
unknown authored
into gleb.loc:/home/uchum/work/bk/4.1-opt
-
- 23 Jun, 2007 1 commit
-
-
unknown authored
into mysql.com:/home/ram/work/b29079/b29079.4.1
-
- 22 Jun, 2007 1 commit
-
-
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.
-
- 20 Jun, 2007 1 commit
-
-
unknown authored
into magare.gmz:/home/kgeorge/mysql/autopush/B29116-4.1-opt
-
- 19 Jun, 2007 4 commits
-
-
unknown authored
counters from relay Updated the test to return columns vertically. mysql-test/r/rpl_change_master.result: Bug #29116: test updated mysql-test/t/rpl_change_master.test: Bug #29116: test updated
-
unknown authored
into pilot.(none):/data/msvensson/mysql/mysql-4.1-maint
-
unknown authored
- Add test case for this already existing feature mysql-test/r/mysqltest.result: Update result file mysql-test/t/mysqltest.test: Add test case for this feature
-
unknown authored
we use net->vio in my_net_local_init, but in the my_net_init implementation we set it after the call, so work with unspecified net->vio value sql/net_serv.cc: Bug #29117 (init_file test crashes with embedded server) as we started using net->vio in my_net_local_init, we should set it before the call
-
- 18 Jun, 2007 5 commits
-
-
unknown authored
into maint1.mysql.com:/data/localhome/tsmith/bk/maint/41 configure.in: Auto merged
-
unknown authored
into trift2.:/MySQL/M41/push-4.1
-
unknown authored
into pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-4.1-build
-
unknown authored
-
unknown authored
into trift2.:/MySQL/M41/push-4.1
-