- 03 Apr, 2007 1 commit
-
-
igor@olga.mysql.com authored
IN/BETWEEN predicates in sorting expressions. Wrong results may occur when the select list contains an expression with IN/BETWEEN predicate that differs from a sorting expression by an additional NOT only. Added the method Item_func_opt_neg::eq to compare correctly expressions containing [NOT] IN/BETWEEN. The eq method inherited from the Item_func returns TRUE when comparing 'a IN (1,2)' with 'a NOT IN (1,2)' that is not, of course, correct.
-
- 31 Mar, 2007 1 commit
-
-
ibabaev@bk-internal.mysql.com authored
into bk-internal.mysql.com:/data0/bk/mysql-4.1-opt
-
- 30 Mar, 2007 2 commits
-
-
sergefp@mysql.com authored
Pushbuild fixes: - Make MAX_SEL_ARGS smaller (even 16K records_in_range() calls is more than it makes sense to do in typical cases) - Don't call sel_arg->test_use_count() if we've already allocated more than MAX_SEL_ARGs elements. The test will succeed but will take too much time for the test suite (and not provide much value).
-
kent@mysql.com/kent-amd64.(none) authored
into mysql.com:/home/kent/bk/tmp/mysql-4.1-build
-
- 29 Mar, 2007 1 commit
-
-
sergefp@mysql.com authored
- Post-review fixes
-
- 28 Mar, 2007 9 commits
-
-
sergefp@mysql.com authored
into mysql.com:/home/psergey/mysql-4.1-bug26624-r2
-
sergefp@mysql.com authored
- Added PARAM::alloced_sel_args where we count the # of SEL_ARGs created by SEL_ARG tree cloning operations. - Made the range analyzer to shortcut and not do any more cloning if we've already created MAX_SEL_ARGS SEL_ARG objects in cloning. - Added comments about space complexity of SEL_ARG-graph representation.
-
sergefp@mysql.com authored
-
sergefp@mysql.com authored
- Define Sql_alloc::operator new() as thow() so that C++ compiler handles NULL return values (there is no testcase as there is no portable way to set limit on the amount of memory that a process can allocate)
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-4.1-axmrg
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-4.1-axmrg
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-4.1-axmrg
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-4.1-axmrg
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-4.1-bug24985
-
- 27 Mar, 2007 2 commits
-
-
kent@mysql.com/kent-amd64.(none) authored
Don't use explicit calls to mysql-test-run in spec
-
istruewing@chilla.local authored
causes incorrect duplicate entries Keys for BTREE indexes on ENUM and SET columns of MEMORY tables with character set UTF8 were computed incorrectly. Many different column values got the same key value. Apart of possible performance problems, it made unique indexes of this type unusable because it rejected many different values as duplicates. The problem was that multibyte character detection was tried on the internal numeric column value. Many values were not identified as characters. Their key value became blank filled. Thanks to Alexander Barkov and Ramil Kalimullin for the patch, which sets the character set of ENUM and SET key segments to the pseudo binary character set.
-
- 26 Mar, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz[kgeorge] authored
to 0 causes wrong (large) length to be read from the row in _mi_calc_blob_length() when storing NULL values in (e.g) POINT columns. This large length is then used to allocate a block of memory that (on some OSes) causes trouble. Fixed by calling the base class's Field_blob::reset() from Field_geom::reset() that is called when storing a NULL value into the column.
-
- 25 Mar, 2007 2 commits
-
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-4.1--team
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-4.1--main
-
- 24 Mar, 2007 1 commit
-
-
serg@sergbook.mysql.com authored
-
- 23 Mar, 2007 6 commits
-
-
serg@sergbook.mysql.com authored
fixed differently: wake up select_thread with THR_SERVER_ALARM instead
-
serg@sergbook.mysql.com authored
into sergbook.mysql.com:/usr/home/serg/Abk/mysql-4.1
-
serg@sergbook.mysql.com authored
into sergbook.mysql.com:/usr/home/serg/Abk/mysql-4.1
-
serg@sergbook.mysql.com authored
into sergbook.mysql.com:/usr/home/serg/Abk/mysql-4.1
-
serg@sergbook.mysql.com authored
(in thr_alarm.cc it happened too late).
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-4.1-bug26996
-
- 22 Mar, 2007 6 commits
-
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/home/hf/work/mrg/mysql-4.1-opt
-
kent@mysql.com/kent-amd64.(none) authored
Delete: scripts/fill_func_tables.sh .del-fill_help_tables.sh: Delete: scripts/fill_help_tables.sh .del-internals.texi: Delete: Docs/internals.texi
-
kent@mysql.com/kent-amd64.(none) authored
into mysql.com:/home/kent/bk/tmp/mysql-4.1-build
-
kent@mysql.com/kent-amd64.(none) authored
Docs/Books/ Docs/MySQL-logos/ Deleted files Docs/Tutorial-MySQL-final.txt Docs/bk.txt Docs/Support/.cvsignore Docs/Support/colspec-fix.pl Docs/Support/docbook-fixup.pl Docs/Support/docbook-prefix.pl Docs/Support/docbook-split Docs/Support/make-docbook Docs/Support/make-makefile Docs/Support/test-make-manual Docs/Support/test-make-manual-de Docs/Support/trivial-makeinfo-4.0c.patch Docs/Support/xwf Deleted file now in internals main text Docs/my_sys.txt Deleted file now in internals svn tree Docs/net_doc.txt Removed obsolete entries Docs/.cvsignore Added note that info is obsolete Docs/linuxthreads.txt
-
holyfoot/hf@mysql.com/hfmain.(none) authored
fix for cast( AS DATETIME) + 0 operation. I just implemented Item_datetime_typecast::val() method as it is usually done in other classes. Should be fixed more radically in 5.0
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/home/hf/work/mrg/mysql-4.1-opt
-
- 20 Mar, 2007 1 commit
-
-
tsmith@quadxeon.mysql.com authored
- Problem: data separators were copied to a fixed-size buffer on the stack; memcpy was used, without bounds checking; a server crash could result if long FIELDS ENCLOSED BY, etc., was given - Fix: write the separators directly, instead of copying to a buffer first (in select_export::send_data())
-
- 19 Mar, 2007 1 commit
-
-
istruewing@chilla.local authored
Using a MEMORY table BTREE index for scanning for updatable rows could lead to an infinite loop. Everytime a key was inserted into a btree index, the position in the index scan was cleared. The search started from the beginning and found the same key again. Now we do not clear the position on key insert an more.
-
- 17 Mar, 2007 1 commit
-
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-4.1--main
-
- 16 Mar, 2007 2 commits
-
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-4.1-bug25289
-
istruewing@chilla.local authored
when index is used When the table contained TEXT columns with empty contents ('', zero length, but not NULL) _and_ strings starting with control characters like tabulator or newline, the empty values were not found in a "records in range" estimate. Hence count(*) missed these records. The reason was a different set of search flags used for key insert and key range estimation. I decided to fix the set of flags used in range estimation. Otherwise millions of databases around the world would require a repair after an upgrade. The consequence is that the manual must be fixed, which claims that TEXT columns are compared with "end space padding". This is true for CHAR/VARCHAR but wrong for TEXT. See also bug 21335.
-
- 15 Mar, 2007 2 commits
-
-
dlenev@mockturtle.local authored
into mockturtle.local:/home/dlenev/src/mysql-4.1-merge
-
dlenev@mockturtle.local authored
TABLE ... WRITE". CPU hogging occured when connection which had to wait for table lock was serviced by thread which previously serviced connection that was killed (note that connections can reuse threads if thread cache is enabled). One possible scenario which exposed this problem was when thread which provided binlog dump to replication slave was implicitly/automatically killed when the same slave reconnected and started pulling data through different thread/connection. In 5.* versions memory hogging was added to CPU hogging. Moreover in those versions the problem also occured when one killed particular query in connection (using KILL QUERY) and later this connection had to wait for some table lock. This problem was caused by the fact that thread-specific mysys_var::abort variable, which indicates that waiting operations on mysys layer should be aborted (this includes waiting for table locks), was set by kill operation but was never reset back. So this value was "inherited" by the following statements or even other connections (which reused the same physical thread). Such discrepancy between this variable and THD::killed flag broke logic on SQL-layer and caused CPU and memory hogging. This patch tries to fix this problem by properly resetting this member. There is no test-case associated with this patch since it is hard to test for memory/CPU hogging conditions in our test-suite.
-
- 14 Mar, 2007 1 commit
-
-
kent@mysql.com/kent-amd64.(none) authored
into mysql.com:/home/kent/bk/tmp/mysql-4.1-build
-