- 16 Oct, 2007 1 commit
-
-
unknown authored
into polly.(none):/home/kaa/src/maint/mysql-4.1-maint
-
- 11 Oct, 2007 1 commit
-
-
unknown authored
myisam_sort_buffer_size. An incorrect length of the sort buffer was used when calculating the maximum number of keys. When myisam_sort_buffer_size is small enough, this could result in the number of keys < number of BUFFPEK structures which in turn led to use of uninitialized BUFFPEKs. Fixed by correcting the buffer length calculation. myisam/sort.c: Use a correct buffer length when calculating the maximum number of keys. Assert that for each BUFFPEK structure there is at least one corresponding key. Otherwise we would fail earlier and not reach merge_buffers(). mysql-test/r/repair.result: Added a test case for bug #31174. mysql-test/t/repair.test: Added a test case for bug #31174.
-
- 10 Oct, 2007 1 commit
-
-
unknown authored
into polly.(none):/home/kaa/src/maint/mysql-4.1-maint
-
- 04 Oct, 2007 5 commits
-
-
unknown authored
into sin.intern.azundris.com:/home/tnurnberg/30444/41-30444
-
unknown authored
Bug#28878: InnoDB tables with UTF8 character set and indexes cause wrong result for DML When making key reference buffers over CHAR fields whitespace (0x20) must be used to fill in the remaining space in the field's buffer. This is what Field_string::store() does. Fixed Field_string::get_key_image() to do the same. mysql-test/r/innodb_mysql.result: Bug#28878: test case mysql-test/t/innodb_mysql.test: Bug#28878: test case sql/field.cc: Bug#28878: Fill with space instead of binary zeros.
-
unknown authored
into sin.intern.azundris.com:/home/tnurnberg/30444/41-30444
-
unknown authored
The combination of --single-transaction and --master-data requires START TRANSACTION WITH CONSISTENT SNAPSHOT which is available from mysqld 4.1 on. When trying this against an older server, print diagnostic, then, if --force is not given, abort. No test-case given since it would require a mysqld < 4.1. client/mysqldump.c: Bug #30444: 5.0 mysqldump silently allows wrong backup to be taken against a 4.0 database The combination of --single-transaction and --master-data requires START TRANSACTION WITH CONSISTENT SNAPSHOT which is available from mysqld 4.1 on. When trying this against an older server, print diagnostic, then, if --force is not given, abort.
-
unknown authored
and for bug #31070: crash during conversion of charsets Problem: passing a 0 byte length string to some my_mb_wc_XXX() functions leads to server crash due to improper argument check. Fix: properly check arguments passed to my_mb_wc_XXX() functions. mysql-test/include/ctype_common.inc: Fix for bug #31069: crash in 'sounds like' and bug #31070: crash during conversion of charsets - test case. mysql-test/r/ctype_big5.result: Fix for bug #31069: crash in 'sounds like' and bug #31070: crash during conversion of charsets - test result. mysql-test/r/ctype_euckr.result: Fix for bug #31069: crash in 'sounds like' and bug #31070: crash during conversion of charsets - test result. mysql-test/r/ctype_gb2312.result: Fix for bug #31069: crash in 'sounds like' and bug #31070: crash during conversion of charsets - test result. mysql-test/r/ctype_gbk.result: Fix for bug #31069: crash in 'sounds like' and bug #31070: crash during conversion of charsets - test result. mysql-test/r/ctype_uca.result: Fix for bug #31069: crash in 'sounds like' and bug #31070: crash during conversion of charsets - test result. strings/ctype-big5.c: Fix for bug #31069: crash in 'sounds like' and bug #31070: crash during conversion of charsets - check the string length before testing its first byte. strings/ctype-cp932.c: Fix for bug #31069: crash in 'sounds like' and bug #31070: crash during conversion of charsets - check the string length before testing its first byte. strings/ctype-euc_kr.c: Fix for bug #31069: crash in 'sounds like' and bug #31070: crash during conversion of charsets - check the string length before testing its first byte. strings/ctype-gb2312.c: Fix for bug #31069: crash in 'sounds like' and bug #31070: crash during conversion of charsets - check the string length before testing its first byte. strings/ctype-sjis.c: Fix for bug #31069: crash in 'sounds like' and bug #31070: crash during conversion of charsets - check the string length before testing its first byte.
-
- 14 Sep, 2007 1 commit
-
-
unknown authored
into trift2.:/MySQL/M41/push-4.1
-
- 10 Sep, 2007 1 commit
-
-
unknown authored
in get_index_for_order(), don't walk over the end of the index key parts when matching index description and needed ordering. mysql-test/r/delete.result: BUG#30385: Testcase mysql-test/t/delete.test: BUG#30385: Testcase
-
- 04 Sep, 2007 1 commit
-
-
unknown authored
into trift2.:/MySQL/M41/push-4.1
-
- 29 Aug, 2007 5 commits
-
-
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
-
unknown authored
Flag changed name in icc 10 scripts/mysql_config.sh: Flag changed name in icc 10
-
unknown authored
'mysqld_wait_started' don't return prematurely because of an old pidfile
-
unknown authored
-
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'
-
- 13 Aug, 2007 1 commit
-
-
unknown authored
into synthia.local:/home/mydev/mysql-4.1-axmrg
-
- 05 Aug, 2007 1 commit
-
-
unknown authored
into pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-4.1-build
-
- 04 Aug, 2007 1 commit
-
-
unknown authored
into pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-4.1
-
- 02 Aug, 2007 7 commits
-
-
unknown authored
into trift2.:/MySQL/M41/push-4.1
-
unknown authored
into chilla.local:/home/mydev/mysql-4.1-axmrg
-
unknown authored
into production.mysql.com:/usersnfs/jperkin/bk/trees/build/mysql-4.1
-
unknown authored
Fix typo in usage. myisam/myisamchk.c: Fix typo in usage.
-
unknown authored
into ramayana.hindu.god:/home/tsmith/m/bk/maint/41
-
unknown authored
into ramayana.hindu.god:/home/tsmith/m/bk/maint/41
-
unknown authored
into ramayana.hindu.god:/home/tsmith/m/bk/maint/41
-
- 01 Aug, 2007 3 commits
-
-
unknown authored
into production.mysql.com:/usersnfs/jperkin/bk/mysql-4.1-maint
-
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.
-
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.
-
- 31 Jul, 2007 2 commits
-
-
unknown authored
into mysql.com:/home/hf/work/29717/my41-29717 sql/sql_select.cc: Auto merged
-
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
-
- 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 3 commits
-
-
unknown authored
into pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-4.1
-
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 2 commits
-
-
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()
-
unknown authored
into pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-4.1
-
- 17 Jul, 2007 1 commit
-
-
unknown authored
into ramayana.hindu.god:/home/tsmith/m/bk/maint/41
-