- 25 Oct, 2006 1 commit
-
-
malff/marcsql@weblab.(none) authored
-
- 24 Oct, 2006 5 commits
-
-
anozdrin/alik@alik. authored
into alik.:/mnt/raid/alik/MySQL/devel/5.1-rt-bug17486
-
anozdrin/alik@alik. authored
-
anozdrin/alik@alik. authored
-
anozdrin/alik@alik. authored
The problem was that IM stoped guarded instances on shutdown, but didn't wait for them to stop. The fix is to wait for guarded instances to stop before exitting from the main thread. The idea is that Instance-monitoring thread should add itself to Thread_registry so that it will be taken into account on shutdown. However, Thread_registry should not signal it on shutdown in order to not interrupt wait()/waitpid().
-
petr/cps@owlet.local authored
into mysql.com:/home/cps/mysql/devel/5.1-rename-bug
-
- 23 Oct, 2006 3 commits
-
-
kostja@bodhi.local authored
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-5.1-runtime-merge
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-5.1-runtime-merge
-
- 20 Oct, 2006 10 commits
-
-
anozdrin/alik@alik. authored
-
dlenev@mockturtle.local authored
into mockturtle.local:/home/dlenev/src/mysql-5.0-bg15228-2
-
dlenev@mockturtle.local authored
into mockturtle.local:/home/dlenev/src/mysql-5.1-bg15228
-
dlenev@mockturtle.local authored
warnings in sql_trigger.cc and sql_view.cc". According to the current version of C++ standard offsetof() macro can't be used for non-POD types. So warnings were emitted when we tried to use this macro for TABLE_LIST and Table_triggers_list classes. Note that despite of these warnings it was probably safe thing to do. This fix tries to circumvent this limitation by implementing custom version of offsetof() macro to be used with these classes. This hack should go away once we will refactor File_parser class. Alternative approaches such as disabling this warning for sql_trigger.cc/sql_view.cc or for the whole server were considered less explicit. Also I was unable to find a way to disable particular warning for particular _part_ of file in GCC.
-
gkodinov@dl145s.mysql.com authored
into dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.1-opt
-
gkodinov@dl145s.mysql.com authored
into dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.1-opt
-
gkodinov@dl145s.mysql.com authored
into dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.0-opt
-
gkodinov@dl145s.mysql.com authored
into dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.0-opt
-
gkodinov@dl145s.mysql.com authored
into dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-4.1-opt
-
gkodinov@dl145s.mysql.com authored
merge fixes
-
- 19 Oct, 2006 21 commits
-
-
malff/marcsql@weblab.(none) authored
This patch reverts a change introduced by Bug 6951, which incorrectly set thd->abort_on_warning for stored procedures. As per internal discussions about the SQL_MODE=TRADITIONAL, the correct behavior is to *not* abort on warnings even inside an INSERT/UPDATE trigger. Tests for Stored Procedures, Stored Functions, Triggers involving SQL_MODE have been included or revised, to reflect the intended behavior. (reposting approved patch, to work around source control issues, no review needed)
-
svoj@mysql.com/april.(none) authored
-
svoj@april.(none) authored
into mysql.com:/home/svoj/devel/mysql/engines/mysql-5.1-engines
-
gkodinov@dl145s.mysql.com authored
into dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.1-opt
-
gkodinov@dl145s.mysql.com authored
into dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.1-opt
-
svoj@mysql.com/april.(none) authored
-
svoj@mysql.com/april.(none) authored
into mysql.com:/home/svoj/devel/mysql/engines/mysql-5.0-engines
-
gkodinov@dl145s.mysql.com authored
into dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.0-opt
-
gkodinov@dl145s.mysql.com authored
into dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.0-opt
-
svoj@mysql.com/april.(none) authored
into mysql.com:/home/svoj/devel/mysql/engines/mysql-4.1-engines
-
gkodinov@dl145s.mysql.com authored
into dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-4.1-opt
-
svoj@mysql.com/april.(none) authored
into mysql.com:/home/svoj/devel/mysql/engines/mysql-4.1-engines
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.1-merge
-
istruewing@chilla.local authored
Backport from 5.1. Raised STACK_MIN_SIZE for Debian GNU/Linux Sid, Linux kernel 2.6.16, gcc version 3.3.6 (Debian 1:3.3.6-13), libc6-dbg 2.3.6.ds1-4, Pentium4 (x86), BUILD/compile-pentium-debug-max Raised about 100 Bytes above the required minimum.
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21856
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-bug21856
-
kroki/tomash@moonlight.intranet authored
When statement to be prepared contained CREATE PROCEDURE, CREATE FUNCTION or CREATE TRIGGER statements with a syntax error in it, the preparation would fail with syntax error message, but the memory could be corrupted. The problem occurred because we switch memroot when parse stored routine or trigger definitions, and on parse error we restored the original memroot only after performing some memory operations. In more detail: - prepared statement would activate its own memory root to parse the definition of the stored procedure. - SP would reset this memory root with its own memory root to parse SP statements - a syntax error would happen - prepared statement would restore the original memory root - stored procedure would restore what it thinks was the original memory root, but actually was the statement memory root. That led to double free - in destruction of the statement and in a next call to mysql_parse(). The solution is to restore memroot right after the failed parsing.
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.1-merge
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.1-merge
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.0-merge
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.0-merge
-