- 26 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/bug32436/my51-bug32436
-
thek@adventure.(none) authored
Sending several "KILL QUERY" statements to target a connection running "SELECT SLEEP" could freeze the server. The locking order in Item_func_sleep was wrong and this could lead to a dead lock. This patch solves the issue by resolving the locking order properly.
-
- 23 Nov, 2007 2 commits
-
-
kostja@bodhi.(none) authored
into bodhi.(none):/opt/local/work/mysql-5.1-runtime
-
kostja@bodhi.(none) authored
into bodhi.(none):/opt/local/work/mysql-5.1-runtime
-
- 22 Nov, 2007 10 commits
-
-
df@pippilotta.erinye.com authored
into pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.1
-
davi@endora.local authored
into endora.local:/Users/davi/mysql/mysql-5.1-runtime
-
davi@endora.local authored
into endora.local:/Users/davi/mysql/mysql-5.1-runtime
-
davi@endora.local authored
into endora.local:/Users/davi/mysql/mysql-5.0-runtime
-
davi@endora.local authored
FLUSH TABLES WITH READ LOCK fails to properly detect write locked tables when running under low priority updates. The problem is that when trying to aspire a global read lock, the reload_acl_and_cache() function fails to properly check if the thread has a low priority write lock, which later my cause a server crash or deadlock. The solution is to simple check if the thread has any type of the possible exclusive write locks.
-
kostja@bodhi.(none) authored
into bodhi.(none):/opt/local/work/mysql-5.1-runtime
-
kostja@bodhi.(none) authored
Bug#28318.
-
malff@lambda.hsd1.co.comcast.net. authored
into lambda.hsd1.co.comcast.net.:/home/malff/TREE/mysql-5.1-rt-merge
-
malff@lambda.hsd1.co.comcast.net. authored
into lambda.hsd1.co.comcast.net.:/home/malff/TREE/mysql-5.0-rt-merge
-
kostja@bodhi.(none) authored
-
- 21 Nov, 2007 15 commits
-
-
thek@adventure.(none) authored
into adventure.(none):/home/thek/Development/cpp/mysql-5.1-runtime
-
df@pippilotta.erinye.com authored
into pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build
-
df@pippilotta.erinye.com authored
into pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.1-build
-
df@pippilotta.erinye.com authored
into pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.1-build
-
df@pippilotta.erinye.com authored
-
df@pippilotta.erinye.com authored
into pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.1-build
-
mleich@five.local.lan authored
into five.local.lan:/work/trees/mysql-5.0-build-src-clean
-
df@pippilotta.erinye.com authored
-
mleich@five.local.lan authored
into five.local.lan:/work/merge/mysql-5.1-build-31610
-
mleich@five.local.lan authored
Bug#31567 "datadict" tests (all engines) fail: Reference protocol is non-standard build Bug#30418 "datadict" tests (all engines) fail: Dependency on the host name for ordering Modifications: 1. The standard builds (build team) do not contain the collation 'utf8_general_cs'. The common developer builds (compuile-....-max) contain this collation. Solution fitting to both build variants: Exclude the collation 'utf8_general_cs' from result sets. 2. Use mysqltest builtin sorting of result set for the statement where the hostname affects the row order.
-
thek@adventure.(none) authored
into adventure.(none):/home/thek/Development/cpp/bug31153/my51-bug31153
-
thek@adventure.(none) authored
into adventure.(none):/home/thek/Development/cpp/mysql-5.0-runtime
-
tsmith@ramayana.hindu.god authored
into ramayana.hindu.god:/home/tsmith/m/bk/build/51
-
davi@endora.local authored
into endora.local:/Users/davi/mysql/mysql-5.1-runtime
-
tsmith@ramayana.hindu.god authored
In several cases, an error when processing the query would cause mysql to return to the top level without printing warnings. Fix is to always print any available warnings before returning to the top level.
-
- 20 Nov, 2007 10 commits
-
-
davi@endora.local authored
into endora.local:/Users/davi/mysql/mysql-5.1-runtime
-
tsmith@ramayana.hindu.god authored
-
davi@endora.local authored
-
tsmith@ramayana.hindu.god authored
Fixes the following bug: - Bug #32125: Database crash due to ha_innodb.cc:3896: ulint convert_search_mode_to_innobase When unknown find_flag is encountered in convert_search_mode_to_innobase() do not call assert(0); instead queue a MySQL error using my_error() and return the error code PAGE_CUR_UNSUPP. Change the functions that call convert_search_mode_to_innobase() to handle that error code by "canceling" execution and returning appropriate error code further upstream.
-
tsmith@ramayana.hindu.god authored
into ramayana.hindu.god:/home/tsmith/m/inno/nov19/51
-
tsmith@ramayana.hindu.god authored
into ramayana.hindu.god:/home/tsmith/m/inno/nov19/51
-
tsmith@ramayana.hindu.god authored
Fixes the following bugs: - Bug #29560: InnoDB >= 5.0.30 hangs on adaptive hash rw-lock 'waiting for an X-lock' Fixed a race condition in the rw_lock where an os_event_reset() can overwrite an earlier os_event_set() triggering an indefinite wait. NOTE: This fix for windows is different from that for other platforms. NOTE2: This bug is introduced in the scalability fix to the sync0arr which was applied to 5.0 only. Therefore, it need not be applied to the 5.1 tree. If we decide to port the scalability fix to 5.1 then this fix should be ported as well. - Bug #32125: Database crash due to ha_innodb.cc:3896: ulint convert_search_mode_to_innobase When unknown find_flag is encountered in convert_search_mode_to_innobase() do not call assert(0); instead queue a MySQL error using my_error() and return the error code PAGE_CUR_UNSUPP. Change the functions that call convert_search_mode_to_innobase() to handle that error code by "canceling" execution and returning appropriate error code further upstream.
-
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.
-
mleich@five.local.lan authored
into five.local.lan:/work/trees/mysql-5.1-build-src-clean
-