- 08 Oct, 2007 1 commit
-
-
unknown authored
-
- 07 Oct, 2007 1 commit
-
-
unknown authored
into bodhi.(none):/opt/local/work/mysql-5.0-runtime mysql-test/r/sp.result: Auto merged mysql-test/t/sp.test: Auto merged sql/sql_parse.cc: Auto merged
-
- 05 Oct, 2007 1 commit
-
-
unknown authored
into pilot.mysql.com:/data/msvensson/mysql/my50-r-bug30992
-
- 04 Oct, 2007 6 commits
-
-
unknown authored
into moksha.local:/Users/davi/mysql/push/mysql-5.0-runtime
-
unknown authored
This bug is a symptom of the way handler's tables are managed. The most different aspect, compared to the conventional behavior, is that the handler's tables are long lived, meaning that their lifetimes are not bounded by the duration of the command that opened them. For this effect the handler code uses its own list (handler_tables instead of open_tables) to hold open handler tables so that the tables won't be closed at the end of the command/statement. Besides the handler_tables list, there is a hash (handler_tables_hash) which is used to associate handler aliases to tables and to refresh the tables upon demand (flush tables). The current implementation doesn't work properly with refreshed tables -- more precisely when flush commands are issued by other initiators. This happens because when a handler open or read statement is being processed, the associated table has to be opened or locked and, for this matter, the open_tables and handler_tables lists are swapped so that the new table being opened is inserted into the handler_tables list. But when opening or locking the table, if the refresh version is different from the thread refresh version then all used tables in the open_tables list (now handler_tables) are refreshed. In the "refreshing" process the handler tables are flushed (closed) without being properly unlinked from the handler hash. The current implementation also fails to properly discard handlers of dropped tables, but this and other problems are going to be addressed in the fixes for bugs 31397 and 31409. The chosen approach tries to properly save and restore the table state so that no table is flushed during the table open and lock operations. The logic is almost the same as before with the list swapping, but with a working glue code. The test case for this bug is going to be committed into 5.1 because it requires a test feature only avaiable in 5.1 (wait_condition). sql/sql_handler.cc: Backup and reset the open_tables and handler_table lists when opening a new handler table and merge the opened table into the handler_tables list afterwards. When locking, do the same but possibly close the table if a refresh is pending.
-
unknown authored
into trift2.:/MySQL/M50/push-5.0
-
unknown authored
This actually, fix for the patch for bug-27354. The problem with the patch was that Item_func_sp::used_tables() was updated, but Item_func_sp::const_item() was not. So, for Item_func_sp, we had the following inconsistency: - used_tables() returned RAND_TABLE, which means that the item can produce "random" results; - but const_item() returned TRUE, which means that the item is a constant one. The fix is to change Item_func_sp::const_item() behaviour: it must return TRUE (an item is a constant one) only if a stored function is deterministic and each of its arguments (if any) is a constant item. mysql-test/r/sp.result: Update result file. mysql-test/t/sp.test: Add test cases for BUG-31035, BUG-31191, BUG-31226 sql/item_func.cc: Make Item::const_item() be consistent with Item::used_tables().
-
unknown authored
into production.mysql.com:/usersnfs/jperkin/bk/bug-27692/5.0
-
unknown authored
were accidentally removed during a previous rototill of this code. Fixes bug#27692. While it can be argued we should strive to provide a 'secure by default' installation, this happens to be the setup currently documented in the manual as the default, so defer changes that improve security out of the box to a co-ordinated effort later on. For now, make a note about the test databases and anonymous user in mysql_install_db and recommend that mysql_secure_installation be ran for users wishing to remove these defaults. [..re-commit of previously lost change..] scripts/mysql_system_tables_data.sql: Add anonymous accounts. scripts/mysql_install_db.sh: Point users at the mysql_secure_installation script. mysql-test/mysql-test-run.pl: Add a comment where removing anonymous users.
-
- 03 Oct, 2007 1 commit
-
-
unknown authored
It's not possible to use WaitForSingleObject to wait on a CRITICAL_SECTION, instead use the TryEnterCriticalSection function. - if "mutex" was already taken => return EBUSY - if "mutex" was aquired => return 0 include/config-win.h: Make windows.h define TryEnterCriticalSection mysys/my_winthread.c: Use the TryEnterCriticalSection function to implement pthread_mutex_trylock Prevent recursive behaviour by looking at the RecursionCount variable in the CRITICAL_SECTION struct and return EBUSY from function if the mutex was already locked once.
-
- 02 Oct, 2007 1 commit
-
-
unknown authored
Updated variable size arrays to use vector like Jonas did for 5.1 so that my build would not break ndb/test/ndbapi/testScanFilter.cpp: Updated variable size arrays to use vector like Jonas did for 5.1 so that my build would not break
-
- 01 Oct, 2007 3 commits
-
-
unknown authored
into kindahl-laptop.dnsalias.net:/home/bk/b30992-mysql-5.0-runtime include/my_pthread.h: Auto merged
-
unknown authored
Adding support for correct handling of pthread_mutex_trylock() on Win32 systems as well as when using the safe mutexes. include/my_pthread.h: Adding win_pthread_mutex_trylock() function as wrapper function for Windows implementation of pthread_mutex_trylock(). Adding flag to safe_mutex_lock() that is shall not abort if the mutex is already locked and instead return EBUSY since this is the POSIX behaviour. mysys/my_winthread.c: Added Win32 wrappper function to handle pthread_mutex_trylock(). mysys/thr_mutex.c: Added parameter 'try_lock' to safe_mutex_lock() to allow it to do double- duty as a pthread_mutex_trylock() in addition to working as pthread_mutex_lock(). The code needs to return EBUSY instead of throwing an error in the event that the mutex is re-locked (we do not have recursive mutexes), but it also requires some special handling to avoid race conditions when calling the real pthread_mutex_{lock,trylock}().
-
unknown authored
into trift2.:/MySQL/M50/push-5.0
-
- 27 Sep, 2007 2 commits
- 26 Sep, 2007 1 commit
-
-
unknown authored
-
- 25 Sep, 2007 1 commit
-
-
unknown authored
into pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build
-
- 22 Sep, 2007 1 commit
-
-
unknown authored
cmake list are auto-generated and thus still required. Correct fix not yet known. bdb/CMakeLists.txt: Revert previous change, it is incorrect as those files are automatically generated.
-
- 20 Sep, 2007 2 commits
-
-
unknown authored
-
unknown authored
added get_field_default_value() function which obtains default value from the field (used in store_create_info() & get_schema_column_record() functions) mysql-test/r/alter_table.result: result fix mysql-test/r/create.result: result fix mysql-test/r/ctype_collate.result: result fix mysql-test/r/ctype_recoding.result: result fix mysql-test/r/default.result: result fix mysql-test/r/gis.result: result fix mysql-test/r/grant.result: result fix mysql-test/r/information_schema.result: result fix mysql-test/r/key.result: result fix mysql-test/r/mysql.result: result fix mysql-test/r/ps_1general.result: result fix mysql-test/r/show_check.result: result fix mysql-test/r/sp.result: result fix mysql-test/r/type_enum.result: result fix mysql-test/r/type_ranges.result: result fix mysql-test/t/information_schema.test: test case
-
- 19 Sep, 2007 1 commit
-
-
unknown authored
into mysql.com:/home/gluh/MySQL/Merge/5.0-opt
-
- 15 Sep, 2007 1 commit
-
-
unknown authored
Post-fix for bug#27695. mysql-test/t/select.test: Post-fix for bug#27695.
-
- 14 Sep, 2007 13 commits
-
-
unknown authored
into devsrv-b.mysql.com:/data0/gshchepa/mysql-5.0-opt
-
unknown authored
into trift2.:/MySQL/M50/push-5.0
-
unknown authored
into trift2.:/MySQL/M50/push-5.0
-
unknown authored
into trift2.:/MySQL/M41/push-4.1
-
unknown authored
into magare.gmz:/home/kgeorge/mysql/autopush/B31001-5.0-opt
-
unknown authored
The optimizer sets index traversal in reverse order only if there are used key parts that are not compared to a constant. However using the primary key as an ORDER BY suffix rendered the check incomplete : going in reverse order must still be used even if all the parts of the secondary key are compared to a constant. Fixed by relaxing the check and set reverse traversal even when all the secondary index keyparts are compared to a const. Also account for the case when all the primary keys are compared to a constant. mysql-test/r/innodb_mysql.result: Bug #31001: test case mysql-test/t/innodb_mysql.test: Bug #31001: test case sql/sql_select.cc: Bug #31001: - account for the case when all the primary key parts are compared to a constant - force test_if_skip_sort_order to go backwards over the key even when the number of keyparts used is the same as the number of keyparts equal to a constant. (because of the primary key suffix).
-
unknown authored
into mysql.com:/home/psergey/mysql-5.0-bug30324
-
unknown authored
- The bug was caused by COUNT(DISTINCT ...) code using Unique object in a way that assumed that BIT(N) column occupies a contiguous space in temp_table->record[0] buffer. - The fix is to make COUNT(DISTINCT ...) code instruct create_tmp_table to create temporary table with column of type BIGINT, not BIT(N). mysql-test/r/type_bit.result: BUG#30324: Grouping queries with COUNT(DISTINCT bit column) return wrong results - Testcase mysql-test/t/type_bit.test: BUG#30324: Grouping queries with COUNT(DISTINCT bit column) return wrong results - Testcase sql/item_sum.cc: BUG#30324: Grouping queries with COUNT(DISTINCT bit column) return wrong results - Make COUNT(DISTINCT ...) code instruct create_tmp_table to create temporary table with BIGINT, not BIT(N) column.
-
unknown authored
into whalegate.ndb.mysql.com:/home/tomas/mysql-5.0-ndb-merge
-
unknown authored
into whalegate.ndb.mysql.com:/home/tomas/mysql-5.0-ndb-merge
-
unknown authored
into devsrv-b.mysql.com:/data0/gshchepa/mysql-5.0-opt
-
unknown authored
into gleb.loc:/home/uchum/work/bk/5.0-opt-27695
-
unknown authored
into gleb.loc:/home/uchum/work/bk/5.0-opt
-
- 13 Sep, 2007 4 commits
-
-
unknown authored
into trift2.:/MySQL/M50/tmp-5.0
-
unknown authored
Declaring an all space column name in the SELECT FROM DUAL or in a view leads to misleading warning message: "Leading spaces are removed from name ' '". The Item::set_name method has been modified to raise warnings like "Name ' ' has become ''" in case of the truncation of an all space identifier to an empty string identifier instead of the "Leading spaces are removed from name ' '" warning message. sql/item.cc: Fixed bug #27695. The Item::set_name method has been modified to raise warnings like "Name ' ' has become ''" in case of the truncation of an all space identifier to an empty string identifier instead of the "Leading spaces are removed from name ' '" warning message. sql/share/errmsg.txt: Fixed bug #27695. mysql-test/t/select.test: Added test case for bug #27695. mysql-test/r/select.result: Added test case for bug #27695.
-
unknown authored
The problem was that aborted_threads variable was updated twice when a client connection had been aborted. The fix is to refactor a code to have aborted_threads updated only in one place. sql/mysql_priv.h: Make do_command() a private function. sql/sql_parse.cc: 1. Make do_command() a private function; 2. Update aborted_threads in the only one place.
-
unknown authored
into mysql.com:/windows/Linux_space/MySQL/mysql-5.0-ndb
-