- 22 Nov, 2007 1 commit
-
-
kostja@bodhi.(none) authored
-
- 21 Nov, 2007 3 commits
-
-
thek@adventure.(none) authored
into adventure.(none):/home/thek/Development/cpp/mysql-5.1-runtime
-
thek@adventure.(none) authored
into adventure.(none):/home/thek/Development/cpp/bug31153/my51-bug31153
-
davi@endora.local authored
into endora.local:/Users/davi/mysql/mysql-5.1-runtime
-
- 20 Nov, 2007 4 commits
-
-
davi@endora.local authored
into endora.local:/Users/davi/mysql/mysql-5.1-runtime
-
davi@endora.local authored
-
davi@endora.local authored
into endora.local:/Users/davi/mysql/mysql-5.1-runtime
-
davi@endora.local authored
The problem is that DROP TABLE and other DDL statements failed to automatically close handlers associated with tables that were marked for reopen (FLUSH TABLES). The current implementation fails to properly discard handlers of dropped tables (that were marked for reopen) because it searches on the open handler tables list and using the current alias of the table being dropped. The problem is that it must not use the open handler tables list to search because the table might have been closed (marked for reopen) by a flush tables command and also it must not use the current table alias at all since multiple different aliases may be associated with a single table. This is specially visible when a user has two open handlers (using alias) of a same table and a flush tables command is issued before the table is dropped (see test case). Scanning the handler table list is also useless for dropping handlers associated with temporary tables, because temporary tables are not kept in the THD::handler_tables list. The solution is to simple scan the handlers hash table searching for, and deleting all handlers with matching table names if the reopen flag is not passed to the flush function, indicating that the handlers should be deleted. All matching handlers are deleted even if the associated the table is not open.
-
- 19 Nov, 2007 1 commit
-
-
thek@adventure.(none) authored
When the server was out of memory it crashed because of invalid memory access. This patch adds detection for failed memory allocations and make the server output a proper error message.
-
- 15 Nov, 2007 2 commits
-
-
malff@lambda.hsd1.co.comcast.net. authored
into lambda.hsd1.co.comcast.net.:/home/malff/TREE/mysql-5.1-rt-merge
-
anozdrin/alik@station. authored
different error code depending on platform. On Mac OS X, KILL statement issued to kill the current connection would return a different error code and message than on other platforms ('MySQL server has gone away' instead of 'Shutdown in progress'). The reason for this difference was that on Mac OS X we have macro SIGNAL_WITH_VIO_CLOSE defined. This macro forces KILL implementation to close the communication socket of the thread that is being killed. SIGNAL_WITH_VIO_CLOSE macro is defined on platforms where just sending a signal is not a reliable mechanism to interrupt the thread from sleeping on a blocking system call. In a nutshell, closing the socket is a hack to work around an operating system bug and awake the blocked thread no matter what. However, if the thread that is being killed is the same thread that issued KILL statement, closing the socket leads to a prematurely lost connection. At the same time it is not necessary to close the socket in this case, since the thread in question is not inside a blocking system call. The fix, therefore, is to not close the socket if the thread that is being killed is the same that issued KILL statement, even with defined SIGNAL_WITH_VIO_CLOSE.
-
- 14 Nov, 2007 3 commits
-
-
dkatz@damien-katzs-computer.local authored
into damien-katzs-computer.local:/Users/dkatz/cmdline_events_bug
-
dkatz@damien-katzs-computer.local authored
-
dkatz@damien-katzs-computer.local authored
into damien-katzs-computer.local:/Users/dkatz/mysql-5.1-runtime
-
- 13 Nov, 2007 3 commits
-
-
istruewing@stella.local authored
Post pushbuild fix Disabled test on windows due to bug#30459 (DATA/INDEX DIR for partitions not working on windows) Patch from Mattias Jonsson.
-
istruewing@stella.local authored
into stella.local:/home2/mydev/mysql-5.1-bug31210
-
istruewing@stella.local authored
if running as root Every start of a server in the test suite raised that warning. The cause was an unconditionla add of the --user option to the server command line. Only the "root" user (effective user id == 0) must use that option. Added check for effective user id == 0 before adding --user. Thanks to Magnus Svensson for the patch.
-
- 12 Nov, 2007 22 commits
-
-
mattiasj@mattiasj-laptop.(none) authored
into mattiasj-laptop.(none):/home/mattiasj/clones/mysql-5.0-engines_with_main
-
mattiasj@mattiasj-laptop.(none) authored
into mattiasj-laptop.(none):/home/mattiasj/clones/mysql-5.1-last_with_main
-
mattiasj@mattiasj-laptop.(none) authored
into mattiasj-laptop.(none):/home/mattiasj/clones/mysql-5.0-engines_with_main
-
mattiasj@mattiasj-laptop.(none) authored
into mattiasj-laptop.(none):/home/mattiasj/clones/mysql-5.1-last_with_main
-
svoj@june.mysql.com authored
into mysql.com:/home/svoj/devel/mysql/BUG32111/mysql-5.1-engines
-
svoj@june.mysql.com authored
into mysql.com:/home/svoj/devel/mysql/BUG32111/mysql-5.0-engines
-
svoj@mysql.com/june.mysql.com authored
Use proper variable for test.
-
istruewing@stella.local authored
into stella.local:/home2/mydev/mysql-5.1-bug31210
-
anozdrin/alik@station. authored
wait_condition timeout. The problem was that the event thread didn't manage to execute the event in 30 seconds on highly-loaded box. The fix is to increase timeout. This is a fix for the test suite.
-
mattiasj@mattiasj-laptop.(none) authored
into mattiasj-laptop.(none):/home/mattiasj/clones/mysql-5.1-lastfinaltopush
-
mattiasj@mattiasj-laptop.(none) authored
into mattiasj-laptop.(none):/home/mattiasj/clones/mysql-5.1-lastfinaltopush
-
mattiasj@mattiasj-laptop.(none) authored
into mattiasj-laptop.(none):/home/mattiasj/clones/mysql-5.1-lastfinaltopush
-
mattiasj@mattiasj-laptop.(none) authored
into mattiasj-laptop.(none):/home/mattiasj/clones/mysql-5.1-lastfinaltopush
-
mattiasj@mattiasj-laptop.(none) authored
Buffer overflow due to wrong key length in partitioning Changed to the correct key_length function.
-
mattiasj@mattiasj-laptop.(none) authored
Merge fix partition_mgm did not require have_symlink. Moved the test case to partition_symlink, which require have_symlink, and should work on both *nix and Windows
-
istruewing@stella.local authored
partitioned table Post-pushbuild fix Pushbuild detected yet another need for lex initialization in embedded server.
-
anozdrin/alik@station. authored
in stored procedure. The problem was that MySQL used unnecessarily large amounts of memory if user variables were used as an argument to CONCAT or CONCAT_WS -- 16M per each user variable used. Technically, it happened because MySQL used the following allocation strategy for string functions to avoid multiple realloc() calls: in the virtual operation fix_length_and_dec() the attribute max_length was calculated as a sum of max_length values for each argument. Although this approach worked well for small (or fixed) data types, there could be a problem if there as a user variable among the arguments of a string function -- max_length of the function would be 16M (as the max_length of a user variable is 16M). Both CONCAT() and CONCAT_WS() functions suffer from this problem. The fix is to do not use meta-data for allocating memory. The following strategy is proposed instead: allocate the exact length of the result string at the first record, double the amount of memory allocated when it is required. No test case for this bug because there is no way to test memory consumption in a robust way with our test suite.
-
svoj@june.mysql.com authored
into mysql.com:/home/svoj/devel/mysql/BUG32111/mysql-5.1-engines
-
svoj@june.mysql.com authored
into mysql.com:/home/svoj/devel/mysql/BUG32111/mysql-5.0-engines
-
svoj@mysql.com/june.mysql.com authored
-
svoj@mysql.com/june.mysql.com authored
into mysql.com:/home/svoj/devel/mysql/BUG32111/mysql-4.1-engines
-
mats@kindahl-laptop.dnsalias.net authored
Adding missing drop of user created for test case.
-
- 11 Nov, 2007 1 commit
-
-
mattiasj@mattiasj-laptop.(none) authored
causes the Server to crash. Post-pushbuild fix Pushbuild genereted valgrind warnings. Changed function to safer variant.
-