- 24 Jul, 2006 1 commit
-
-
kostja@bodhi.local authored
when calling a SP from C API" The bug was caused by lack of checks for misuse in mysql_real_query. A stored procedure always returns at least one result, which is the status of execution of the procedure itself. This result, or so-called OK packet, is similar to a result returned by INSERT/UPDATE/CREATE operations: it contains the overall status of execution, the number of affected rows and the number of warnings. The client test program attached to the bug did not read this result and ivnoked the next query. In turn, libmysql had no check for such scenario and mysql_real_query was simply trying to send that query without reading the pending response, thus messing up the communication protocol. The fix is to return an error from mysql_real_query when it's called prior to retrieval of all pending results.
-
- 21 Jul, 2006 1 commit
-
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug19207
-
- 20 Jul, 2006 1 commit
-
-
anozdrin/alik@booka.site authored
Fix for the bug in mysql-test-run.pl which prevents other tests succeed after IM-test failure. The idea of the fix of BUG#20716 is to: 1. Check each SHOW INSTANCES statement, add necessary "sleep" instruction before; 2. Move all environment checkings into the one file and include it everywhere.
-
- 17 Jul, 2006 2 commits
-
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21013
-
kroki/tomash@moonlight.intranet authored
and Stored Procedure The essence of the bug was that for every re-execution of stored routine or prepared statement new items for character set conversions were created, thus increasing the number of items and the time of their processing, and creating memory leak. No test case is provided since current test suite can't cover such type of bugs.
-
- 13 Jul, 2006 2 commits
-
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug18630
-
kroki/tomash@moonlight.intranet authored
context. Routine arguments were evaluated in the security context of the routine itself, not in the caller's context. The bug is fixed the following way: - Item_func_sp::find_and_check_access() has been split into two functions: Item_func_sp::find_and_check_access() itself only finds the function and check that the caller have EXECUTE privilege on it. New function set_routine_security_ctx() changes security context for SUID routines and checks that definer have EXECUTE privilege too. - new function sp_head::execute_trigger() is called from Table_triggers_list::process_triggers() instead of sp_head::execute_function(), and is effectively just as the sp_head::execute_function() is, with all non-trigger related code removed, and added trigger-specific security context switch. - call to Item_func_sp::find_and_check_access() stays outside of sp_head::execute_function(), and there is a code in sql_parse.cc before the call to sp_head::execute_procedure() that checks that the caller have EXECUTE privilege, but both sp_head::execute_function() and sp_head::execute_procedure() call set_routine_security_ctx() after evaluating their parameters, and restore the context after the body is executed.
-
- 12 Jul, 2006 3 commits
-
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-5.0-runtime
-
kostja@bodhi.local authored
-
mkindahl@dl145k.mysql.com authored
into dl145k.mysql.com:/data0/mkindahl/bk/mysql-5.0-rpl
-
- 11 Jul, 2006 8 commits
-
-
kostja@bodhi.local authored
when dropping/creating tables"
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-5.0-runtime-merge-41
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-5.0-runtime-merge-41
-
ingo/mydev@chilla.local authored
into chilla.local:/home/mydev/mysql-5.0-amerge
-
joerg@trift2. authored
-
joerg@trift2. authored
into trift2.:/M50/mysql-5.0
-
mkindahl@dl145k.mysql.com authored
into dl145k.mysql.com:/data0/mkindahl/bk/MERGE/mysql-5.0-merge
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-5.0-runtime-merge-41
-
- 10 Jul, 2006 21 commits
-
-
kostja@bodhi.local authored
-
joerg@trift2. authored
into trift2.:/M50/mysql-5.0
-
joerg@trift2. authored
-
kostja@bodhi.local authored
-
ingo/mydev@chilla.local authored
-
guilhem@gbichot3.local authored
into gbichot3.local:/home/mysql_src/mysql-5.0
-
kostja@bodhi.local authored
-
pekka@orca.ndb.mysql.com authored
into orca.ndb.mysql.com:/space_old/pekka/ndb/version/my50-1.2167.1.2
-
pekka@orca.ndb.mysql.com authored
-
pekka@orca.ndb.mysql.com authored
-
kostja@bodhi.local authored
fails"
-
kostja@bodhi.local authored
-
pekka@orca.ndb.mysql.com authored
into orca.ndb.mysql.com:/space_old/pekka/ndb/version/my50
-
pekka@orca.ndb.mysql.com authored
-
into dsl-hkigw8-feb1fb00-100.dhcp.inet.fi:/usr_rh9/home/elkin.rh9/MySQL/TEAM/FIXES/5.0/20919_temp_nlog
-
joerg@trift2. authored
into trift2.:/M50/mysql-5.0
-
joerg@trift2. authored
-
joerg@trift2. authored
into trift2.:/M50/back23-5.0
-
pekka@orca.ndb.mysql.com authored
into orca.ndb.mysql.com:/space_old/pekka/ndb/version/my50-bug20847
-
pekka@orca.ndb.mysql.com authored
-
pekka@orca.ndb.mysql.com authored
into orca.ndb.mysql.com:/space_old/pekka/ndb/version/my50-bug20847
-
- 09 Jul, 2006 1 commit
-
-
closing temp tables through end_thread had a flaw in binlog-off branch of close_temporary_tables where next table to close was reset via table->next for (table= thd->temporary_tables; table; table= table->next) which was wrong since the current table instance got destoyed at close_temporary(table, 1); The fix adapts binlog-on branch method to engage the loop's internal 'next' variable which holds table->next prior table's destoying.
-