- 25 Aug, 2006 1 commit
-
-
kroki/tomash@moonlight.intranet authored
-
- 24 Aug, 2006 2 commits
-
-
andrey@example.com authored
The following procedure was not possible if max_sp_recursion_depth is 0 create procedure show_proc() show create procedure show_proc; Actually there is no recursive call but the limit is checked. Solved by temporarily increasing the thread's limit just before the fetch from cache and decreasing after that.
-
kroki/tomash@moonlight.intranet authored
Changes in an item tree done by optimizer weren't properly registered and went unnoticed, which resulted in preliminary freeing of used memory.
-
- 23 Aug, 2006 2 commits
-
-
anozdrin/alik@alik. authored
User name (host name) has limit on length. The server code relies on these limits when storing the names. The problem was that sometimes these limits were not checked properly, so that could lead to buffer overflow. The fix is to check length of user/host name in parser and if string is too long, throw an error.
-
malff/marcsql@weblab.(none) authored
Implemented code review comments Test cleanup
-
- 22 Aug, 2006 3 commits
-
-
malff/marcsql@weblab.(none) authored
into weblab.(none):/home/marcsql/TREE/mysql-5.0-8153
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21051-2
-
kroki/tomash@moonlight.intranet authored
There were two problems: RESET QUERY CACHE took a long time to complete and other threads were blocked during this time. The patch does three things: 1 fixes a bug with improper use of test-lock-test_again technique. AKA Double-Checked Locking is applicable here only in few places. 2 Somewhat improves performance of RESET QUERY CACHE. Do my_hash_reset() instead of deleting elements one by one. Note however that the slowdown also happens when inserting into sorted list of free blocks, should be rewritten using balanced tree. 3 Makes RESET QUERY CACHE non-blocking. The patch adjusts the locking protocol of the query cache in the following way: it introduces a flag flush_in_progress, which is set when Query_cache::flush_cache() is in progress. This call sets the flag on enter, and then releases the lock. Every other call is able to acquire the lock, but does nothing if flush_in_progress is set (as if the query cache is disabled). The only exception is the concurrent calls to Query_cache::flush_cache(), that are blocked until the flush is over. When leaving Query_cache::flush_cache(), the lock is acquired and the flag is reset, and one thread waiting on Query_cache::flush_cache() (if any) is notified that it may proceed.
-
- 21 Aug, 2006 2 commits
-
-
dlenev@mockturtle.local authored
into mockturtle.local:/home/dlenev/src/mysql-5.0-bg21216-2
-
dlenev@mockturtle.local authored
server to crash". Crash caused by assertion failure happened when one ran SHOW OPEN TABLES while concurrently doing DROP TABLE (or RENAME TABLE, CREATE TABLE LIKE or any other command that takes name-lock) in other connection. For non-debug version of server problem exposed itself as wrong output of SHOW OPEN TABLES statement (it was missing name-locked tables). Finally in 5.1 both debug and non-debug versions simply crashed in this situation due to NULL-pointer dereference. This problem was caused by the fact that table placeholders which were added to table cache in order to obtain name-lock had TABLE_SHARE::table_name set to 0. Therefore they broke assumption that this member is non-0 for all tables in table cache which was checked by assert in list_open_tables() (in 5.1 this function simply relies on it). The fix simply sets this member for such placeholders to appropriate value making this assumption true again. This patch also includes test for similar bug 12212 "Crash that happens during removing of database name from cache" reappeared in 5.1 as bug 19403.
-
- 19 Aug, 2006 1 commit
-
-
malff/marcsql@weblab.(none) authored
Corrected build issues : the build can not be conditional. to keep a unique source .tar.gz distribution.
-
- 17 Aug, 2006 1 commit
-
-
malff/marcsql@weblab.(none) authored
Changed the automake build process : - ./configure.in - ./sql/Makefile.am to compile an instrumented parser for debug=yes or debug=full builds Changed the (primary) runtime invocation of the parser : - sql/sql_parse.cc to generate bison traces in stderr when the DBUG "parser_debug" flag is set.
-
- 15 Aug, 2006 1 commit
-
-
petr/cps@mysql.com/owlet authored
into mysql.com:/home/cps/mysql/trees/mysql-5.0-virgin
-
- 03 Aug, 2006 1 commit
-
-
malff/marcsql@weblab.(none) authored
Before this fix, - a runtime error in a statement in a stored procedure with no error handlers was properly detected (as expected) - a runtime error in a statement with an error handler inherited from a non local runtime context (i.e., proc a with a handler, calling proc b) was properly detected (as expected) - a runtime error in a statement with a *local* error handler was executed as follows : a) the statement would succeed, regardless of the error condition, (bug) b) the error handler would be called (as expected). The root cause is that functions like my_messqge_sql would "forget" to set the thread flag thd->net.report_error to 1, because of the check involving sp_rcontext::found_handler_here(). Failure to set this flag would cause, later in the call stack, in Item_func::fix_fields() at line 190, the code to return FALSE and consider that executing the statement was successful. With this fix : - error handling code, that was duplicated in different places in the code, is now implemented in sp_rcontext::handle_error(), - handle_error() correctly sets thd->net.report_error when a handler is present, regardless of the handler location (local, or in the call stack). A test case, bug8153_subselect, has been written to demonstrate the change of behavior before and after the fix. Another test case, bug8153_function_a, as also been writen. This test has the same behavior before and after the fix. This test has been written to demonstrate that the previous expected result of procedure bug18787, was incorrect, since select no_such_function() should fail and therefore not produce a result. The incorrect result for bug18787 has the same root cause as Bug#8153, and the expected result has been adjusted.
-
- 02 Aug, 2006 15 commits
-
-
kostja@bodhi.local authored
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-5.0-runtime-merge
-
kostja@bodhi.local authored
-
evgen@moonbone.local authored
into moonbone.local:/work/tmp_merge-5.0-opt-mysql
-
evgen@moonbone.local authored
into moonbone.local:/work/tmp_merge-5.0-opt-mysql
-
evgen@moonbone.local authored
into moonbone.local:/work/tmp_merge-5.0-opt-mysql
-
evgen@moonbone.local authored
into moonbone.local:/work/tmp_merge-5.0-opt-mysql
-
evgen@moonbone.local authored
into moonbone.local:/work/tmp_merge-4.1-opt-mysql
-
evgen@moonbone.local authored
into moonbone.local:/work/tmp_merge-4.1-opt-mysql
-
holyfoot/hf@mysql.com/deer.(none) authored
into mysql.com:/home/hf/work/mysql-4.1.20317
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-5.0-runtime-merge
-
georg@lmy002.wdf.sap.corp authored
into lmy002.wdf.sap.corp:/home/georg/work/mysql/prod/mysql-5.0
-
kostja@bodhi.local authored
-
georg@lmy002.wdf.sap.corp authored
-
tsmith@maint1.mysql.com authored
Delete: mysql-test/t/sp.test.orig
-
- 01 Aug, 2006 9 commits
-
-
tsmith@maint1.mysql.com authored
Fixes: - bug #19834: Using cursors when running in READ-COMMITTED can cause InnoDB to crash - bug #21112: InnoDB slow with > 100,000 .ibd files - bug #21113: Duplicate printout in SHOW INNODB STATUS
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-4.1
-
gkodinov/kgeorge@rakia.(none) authored
into rakia.(none):/home/kgeorge/mysql/autopush/B20103-5.0-opt
-
gkodinov/kgeorge@macbook.gmz authored
- make the client to respect the server-side no_backslash_escapes option and disable the special meaning of backslash also at client side.
-
into mysql.com:/users/lthalmann/bk/MERGE/mysql-5.0-merge
-
into mysql.com:/users/lthalmann/bk/MERGE/mysql-4.1-merge
-
gkodinov/kgeorge@rakia.(none) authored
into rakia.(none):/home/kgeorge/mysql/autopush/B11551-5.0-opt
-
evgen@sunlight.local authored
into sunlight.local:/local_work/tmp_merge-5.0-opt-mysql
-
into mysql.com:/users/lthalmann/bk/MERGE/mysql-5.0-merge
-
- 31 Jul, 2006 2 commits
-
-
into mysql.com:/users/lthalmann/bk/MERGE/mysql-5.0-merge
-
into mysql.com:/users/lthalmann/bk/MERGE/mysql-4.1-merge
-