- 14 Mar, 2011 4 commits
-
-
Davi Arnaut authored
-
Davi Arnaut authored
Add a missing DBUG_RETURN function test_if_number().
-
Magne Mahre authored
INSTALLATION When starting mysqld as an MS Windows NT service, it crashed with "Error 1067: The process terminated unexpectedly". The problem is that thread local variables are not allocated and initialized properly when started as a service. When the server is started as a regular executable, the problem does not occur. Analysis showed that this is a regression after the patch for Bug#11765237/Bug#11763065. Before, the thread local storage was initialized by the call chain: win_main->my_basic_init->my_thread_basic_global_init-> my_thread_init When the my_init() structure was changed, this initialization was moved from win_main to mysqld_main. When started as a service win_main is run in a separate thread, which does not have mysqld_main in its call path, so my_thread_init is never called for this thread. Added a call to my_thread_init / my_thread_end in the service handler function, which solves the problem.
-
Alexander Nozdrin authored
fails when running with ps-protocol). The problem was that when running in --ps-protocol mode mysqltest.cc didn't close created prepared statements. So, the plugins could not be unistalled because there was a prepared statement using them. A fix is to add a dummy statement that forces mysqltest.cc to close the last prepared statement (which uses a plugin-defined table).
-
- 11 Mar, 2011 10 commits
-
-
Joerg Bruehe authored
When a RPM test build in a non-release branch is done, the $MYSQL_BINDIR variable ends in "/usr" (rather than in "/usr/lib" as in a RPM release build), this made test "file_contents" fail. A branch for this case is added to the test. The test result is unchanged. mysql-test/t/file_contents.test: Fight a problem in internal test builds: When a RPM test build in a non-release branch is done, the $MYSQL_BINDIR variable ends in "/usr" (rather than in "/usr/lib" as in a RPM release build), this made test "file_contents" fail. Because of this, the old logic did not recognize that a RPM build is done (trailing '/' missing!) and took the tar.gz branch. Just removing the trailing '/' from the "/usr" is not enough, as the logic for RPMs used to replace "/lib" which is not present at all; rather, a new branch was added. To help in case of future problems, the error messages for a failing "open()" now also report "$MYSQL_BINDIR".
-
Bjorn Munch authored
-
Bjorn Munch authored
-
Bjorn Munch authored
-
Mayank Prasad authored
-
Mayank Prasad authored
Issue: SSL_CIPHER set to a specific CIPHER name was not getting picked up by SHOW STATUS Command. Solution: If specific cipher name is specified, avoid overwriting of Cipher List with default Cipher names. extra/yassl/src/yassl_int.cpp: If user specified Cipher name is there, avoid populating default cipher names' list. mysql-test/r/ssl_cipher.result: Expected file for ssl_cipher.test test case mysql-test/t/ssl_cipher-master.opt: Server option file for ssl_cipher.test test case. mysql-test/t/ssl_cipher.test: Test case to verify that user specified SSL cipher name is shown in SHOW STATUS Command.
-
Marc Alff authored
-
Bjorn Munch authored
-
Bjorn Munch authored
-
Bjorn Munch authored
-
- 10 Mar, 2011 8 commits
-
-
Marc Alff authored
-
Marc Alff authored
-
Marc Alff authored
-
Alexander Nozdrin authored
pre-locking list caused by triggers). The thing is that CREATE TRIGGER / DROP TRIGGER may actually change pre-locking list of (some) stored routines. The SP-cache does not detect such changes. Thus if sp_head-instance is cached in SP-cache, subsequent executions of the cached sp_head will use inaccurate pre-locking list. The patch is to invalidate SP-cache on CREATE TRIGGER / DROP TRIGGER.
-
Marc Alff authored
improved the result file readability.
-
Anitha Gopi authored
-
Anitha Gopi authored
-
Anitha Gopi authored
-
- 09 Mar, 2011 5 commits
-
-
Mattias Jonsson authored
-
Mattias Jonsson authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
- 08 Mar, 2011 6 commits
-
-
Bjorn Munch authored
-
Bjorn Munch authored
-
Bjorn Munch authored
-
Bjorn Munch authored
-
Marc Alff authored
Before this fix, two performance schema unit tests crashed on windows. The problem was a missing initialization to PFS_atomics, which caused the crash only for platform not compiled with native atomics. This fix adds the missing initialization in the unit tests. No production code was changed, this is a unit test bug only.
-
Jon Olav Hauglid authored
MAP 'REPAIR TABLE' TO RECREATE +ANALYZE FOR ENGINES NOT SUPPORTING NATIVE REPAIR Executing 'mysqlcheck --check-upgrade --auto-repair ...' will first issue 'CHECK TABLE FOR UPGRADE' for all tables in the database in order to check if the tables are compatible with the current version of MySQL. Any tables that are found incompatible are then upgraded using 'REPAIR TABLE'. The problem was that some engines (e.g. InnoDB) do not support 'REPAIR TABLE'. This caused any such tables to be left incompatible. As a result such tables were not properly fixed by the mysql_upgrade tool. This patch fixes the problem by first changing 'CHECK TABLE FOR UPGRADE' to return a different error message if the engine does not support REPAIR. Instead of "Table upgrade required. Please do "REPAIR TABLE ..." it will report "Table rebuild required. Please do "ALTER TABLE ... FORCE ..." Second, the patch changes mysqlcheck to do 'ALTER TABLE ... FORCE' instead of 'REPAIR TABLE' in these cases. This patch also fixes 'ALTER TABLE ... FORCE' to actually rebuild the table. This change should be reflected in the documentation. Before this patch, 'ALTER TABLE ... FORCE' was unused (See Bug#11746162) Test case added to mysqlcheck.test client/mysqlcheck.c: Changed mysqlcheck to do 'ALTER TABLE ... FORCE' if 'CHECK TABLE FOR UPGRADE' reports ER_TABLE_NEEDS_REBUILD and not ER_TABLE_NEEDS_UPGRADE. mysql-test/r/mysqlcheck.result: Added regression test. mysql-test/std_data/bug47205.frm: InnoDB 5.0 FRM which contains a varchar primary key using utf8_general_ci. This is an incompatible FRM for 5.5. mysql-test/t/mysqlcheck.test: Added regression test. sql/handler.h: Added new HA_CAN_REPAIR flag. sql/share/errmsg-utf8.txt: Added new error message ER_TABLE_NEEDS_REBUILD sql/sql_admin.cc: Changed 'CHECK TABLE FOR UPDATE' to give ER_TABLE_NEEDS_REBUILD instead of ER_TABLE_NEEDS_UPGRADE if the engine does not support REPAIR (as indicated by the new HA_CAN_REPAIR flag). sql/sql_lex.h: Remove unused ALTER_FORCE flag. sql/sql_yacc.yy: Make sure ALTER TABLE ... FORCE recreates the table by setting the ALTER_RECREATE flag as the ALTER_FORCE flag was unused. storage/archive/ha_archive.h: Added new HA_CAN_REPAIR flag to Archive storage/csv/ha_tina.h: Added new HA_CAN_REPAIR flag to CSV storage/federated/ha_federated.h: Added new HA_CAN_REPAIR flag to Federated storage/myisam/ha_myisam.cc: Added new HA_CAN_REPAIR flag to MyISAM
-
- 07 Mar, 2011 2 commits
-
-
Jon Olav Hauglid authored
NON-PRIMARY UNIQUE INDEX USING INNODB This patch adds the HA_INPLACE_ADD_UNIQUE_INDEX_NO_WRITE capability flag to InnoDB, indicating that concurrent reads can be allowed while non-primary unique indexes are created. This is an follow-up to Bug #11751388 which enabled concurrent reads when creating non-primary non-unique indexes. Test case added to innodb_mysql_sync.test.
-
Jon Olav Hauglid authored
FLUSH TABLES under FLUSH TABLES <list> WITH READ LOCK leads to assert failure. This assert was triggered if a statement tried up upgrade a metadata lock with an active FLUSH TABLE <list> WITH READ LOCK. The assert checks that the connection already holds a global intention exclusive metadata lock. However, FLUSH TABLE <list> WITH READ LOCK does not acquire this lock in order to be compatible with FLUSH TABLES WITH READ LOCK. Therefore any metadata lock upgrade caused the assert to be triggered. This patch fixes the problem by preventing metadata lock upgrade if the connection has an active FLUSH TABLE <list> WITH READ LOCK. ER_TABLE_NOT_LOCKED_FOR_WRITE will instead be reported to the client. Test case added to flush.test.
-
- 04 Mar, 2011 3 commits
-
-
Alexander Barkov authored
@ mysql-test/r/ctype_latin1.result @ mysql-test/r/ctype_utf8.result @ mysql-test/t/ctype_latin1.test @ mysql-test/t/ctype_utf8.test Adding tests @ sql/mysqld.h @ sql/item.cc @ sql/sql_parse.cc @ sql/sql_view.cc Refactoring (thanks to Guilhem for the idea): Item_string::print() was hard to understand because of the different QT_ constants: in "query_type==QT_x", QT_x is explicitely included but the other two QT_ are implicitely excluded. The combinations with '||' and '&&' make this even harder. - logic is now more "explicit" by changing QT_ constants to a bitmap of flags: QT_ORDINARY: no change, QT_IS -> QT_TO_SYSTEM_CHARSET | QT_WITHOUT_INTRODUCERS, QT_EXPLAIN -> QT_TO_SYSTEM_CHARSET (QT_EXPLAIN was introduced in the first version of the Bug#57341 patch) - Item_string::print() is rewritten using those flags Bugfix itself: When QT_TO_SYSTEM_CHARSET is used alone (with no QT_WITHOUT_INTRODUCERS), we print string literals as follows: - display introducers if they were in the original query - print ASCII characters as is - print non-ASCII characters using hex-escape Note: as "EXPLAIN" output is only for human readability purposes and does not need to be a pasrable SQL, so using hex-escape is Ok. ErrConvString class perfectly suites for hex escaping purposes.
-
Nirbhay Choubey authored
CLIENT CONFIGURATION. At startup, MySQL server/client programs do not read configuration file pointed by MYSQL_HOME environment variable. This happened as, this environment variable was handled by a different variable (DEFAULT_HOME_ENV) in the code, which was ne'er initialized. Fixed by changing it to MYSQL_HOME. mysys/default.c: BUG 11766219 : 59280: $MYSQL_HOME IS NOT USED FOR THE CLIENT CONFIGURATION. In the current build environment, the variable DEFAULT_HOME_ENV is no more found being initialized to MYSQL_HOME (as was the case earlier). Changed the variable name to MYSQL_HOME.
-
Jorgen Loland authored
from 5.1 to 5.5 (Former 59405) In this bug, args[0] in an Item_func_find_in_set stored an Item_func_weekday that was constant. In Item_func_find_in_set::fix_length_and_dec(), args[0]->val_str() was called. Later, when Item_func_find_in_set::val_int() was called, args[0]->null_value was checked. However, the Item_func_weekday in args[0] had now been replaced with an Item_cache. No val_*() calls had been made to this Item_cache, thus null_value was incorrectly 'true', resulting in missing rows in the result set. enum_value gets a value in fix_length_and_dec() iff args[0] is both constant and non-null. It is therefore unnecessary to check the null_value of args[0] in val_int(). An alternative fix would be to call args[0]->val_int() inside Item_func_find_in_set::val_int(). This would ensure args[0]->null_value was set correctly (always false in this case), but that would have to be done for every record this const value is checked against. mysql-test/r/func_set.result: Add test for BUG#59405 mysql-test/t/func_set.test: Add test for BUG#59405
-
- 03 Mar, 2011 2 commits
-
-
MySQL Build Team authored
-
unknown authored
-