- 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.
-
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.
-
- 03 Mar, 2011 9 commits
-
-
MySQL Build Team authored
-
Alexander Barkov authored
-
Alexander Barkov authored
Part 2. Function QUOTE() was not multi-byte safe. @ mysql-test/r/ctype_ucs.result @ mysql-test/t/ctype_ucs.test Adding tests @ sql/item_strfunc.cc Fixing Item_func_quote::val_str to be multi-byte safe. @ sql/item_strfunc.h Multiple size needed for quote characters to mbmaxlen
-
Alexander Barkov authored
-
Alexander Barkov authored
Problem: wrong character set pointer was passed to my_strtoll10_mb2, which led to DBUG_ASSERT failure in some cases. @ mysql-test/r/func_encrypt_ucs2.result @ mysql-test/t/func_encrypt_ucs2.test @ mysql-test/r/ctype_ucs.result @ mysql-test/t/ctype_ucs.test Adding tests @ sql/item_func.cc "cs" initialization was wrong (res does not necessarily point to &str_value) @ sql/item_strfunc.cc Item_func_dec_encrypt::val_str() and Item_func_des_descrypt::val_str() did not set character set for tmp_value (the returned value), so the old value, which was previously copied from args[1]->val_str(), was incorrectly returned with tmp_value.
-
Alexander Barkov authored
-
Alexander Barkov authored
Bug#11765108 - Bug#58036: CLIENT UTF32, UTF16, UCS2 SHOULD BE DISALLOWED, THEY CRASH SERVER Fixing wrong usage of DBUG_ASSERT. In non-debug version thd_init_client_charset was not executed at all.
-
Anitha Gopi authored
Bug#11769332 : These tests crash on windows which leads to cdb hang. This results in very long runtime. Disable till the bug is fixed
-
Anitha Gopi authored
Bug#11769332 : Disable in daily runs till the bug is fixed. These tests crash the server abd can lead to cdb hang on windows
-
- 02 Mar, 2011 1 commit
-
-
Davi Arnaut authored
Post-merge fix: equal sign is now meaningless, the string being printed was already preceded by a colon.
-
- 01 Mar, 2011 8 commits
-
-
Vinay Fisrekar authored
-
Vinay Fisrekar authored
Result File Correction For Bug Fix
-
Alexander Barkov authored
-
Magne Mahre authored
-
Alexander Barkov authored
Problem: a byte behind the end of input string was read in case of a broken XML not having a quote or doublequote character closing a string value. Fix: changing condition not to read behind the end of input string @ mysql-test/r/xml.result @ mysql-test/t/xml.test Adding tests @ strings/xml.c When checking if the closing quote/doublequote was found, using p->cur[0] us unsafe, as p->cur can point to the byte after the value. Comparing p->cur to p->beg instead.
-
Alexander Barkov authored
Problem: in case of string CASE/WHEN arguments with different character sets, Item_func_case::find_item() called comparator cmp_items[x] on mixed character set Items, so a 8-bit value could be errouneously referenced to as being utf16/utf32 value, which led to crash on DBUG_ASSERT() because of wrong value length. This was wrong, as string comparator expects arguments in the same character set. Fix: modify Item_func_case's argument list after calling agg_arg_charsets_for_comparison() - put the Items in "agg" array back to "args", because some of the Items in the "agg" array might have been changed to character set converters: - to Item_func_conv_charset for non-constant items - to Item_string for constant items In other words, perform the same substitution which is done in all other operations string comparison or string result operations: Replace CASE latin1_item WHEN utf16_item THEN ... END to CASE CONVERT(latin1_item USING utf16) WHEN utf16_item THEN ... END Replace CASE utf16_item WHEN latin1_item THEN ... END to CASE utf16_item WHEN CONVERT(latin1_item USING utf16) THEN ... END @ mysql-test/r/ctype_utf16.result @ mysql-test/r/ctype_utf32.result @ mysql-test/t/ctype_utf16.test @ mysql-test/t/ctype_utf32.test Adding tests @ sql/item_cmpfunc.cc Put "agg" back to "args". @ sql/sql_string.cc Backporting a fix for String::set_or_copy_aligned() from 5.6, for better test coverage: "SELECT _utf16 0x61" should expand the string to 0x0061 rather than to 0x000061. This fix was made in 5.6 under terms of "WL#4616 Implement UTF16-LE".
-
Magne Mahre authored
Bug#11763065 - 55730: KILL_SERVER() CALLS SETEVENT ON A NULL HANDLE, SMEM_EVENT_CONNECT_REQUEST Application Verifier is a Microsoft tool used for detecting certain classes of programming errors. In particular, MS Windows OS resource usage is monitored for wrong usage (handles, thread local storage, critical sections, ...) In MySQL 5.5.x, an error was introduced where an object on thread local storage was used before the TLS and the object was created. The fix has been to move the mysys initialization to an earlier stage in the boot process when built for Windows. For non-win builds, the init already happens early. Some un-tangling of calls to my_init(), my_basic_init() and my_thread_global_init() was done. There is no longer a need to do init in steps, so the full my_init() is called instead of my_init_basic(). In addition, Bug#11763065 was fixed. The event handle 'smem_event_connect_request' is only created if 'opt_enable_shared_memory' is set. When killing the server, an event was flagged on the handle unconditionally. Added a test, so it will only be flagged if created.
-
Dmitry Lenev authored
IS FAILING". The problem was that large_tests.lock_tables_big test was failing due to exceeding open files limit on platforms where this limit was set too low (this test simultaneously opens approx. 6000 files). This patch solves this issue by ensuring that this test is skipped on such platforms.
-
- 27 Feb, 2011 1 commit
-
-
Serge Kozlov authored
-
- 24 Feb, 2011 1 commit
-
-
Tor Didriksen authored
-
- 23 Feb, 2011 6 commits
-
-
Vasil Dimov authored
-
Vasil Dimov authored
-
Jon Olav Hauglid authored
Assertion `bitmap_is_set_all(&table->s->all_set)' failed in handler::ha_reset Post-push fix for unit test compilation error on Windows.
-
Sunny Bains authored
-
Sunny Bains authored
-
Sunny Bains authored
the trunk.
-
- 22 Feb, 2011 7 commits
-
-
hery.ramilison@oracle.com authored
-
Sunny Bains authored
-
Sunny Bains authored
in 5.5 and trunk. First we remove the file in the commit.
-
Nirbhay Choubey authored
-
Nirbhay Choubey authored
-
Sunny Bains authored
-
Sunny Bains authored
Bug #11766501: Multiple RBS break the get rseg with mininum trx_t::no code during purge Bug# 59291 changes: Main problem is that truncating the UNDO log at the completion of every trx_purge() call is expensive as the number of rollback segments is increased. We truncate after a configurable amount of pages. The innodb_purge_batch_size parameter is used to control when InnoDB does the actual truncate. The truncate is done once after 128 (or TRX_SYS_N_RSEGS iterations). In other words we truncate after purge 128 * innodb_purge_batch_size. The smaller the batch size the quicker we truncate. Introduce a new parameter that allows how many rollback segments to use for storing REDO information. This is really step 1 in allowing complete control to the user over rollback space management. New parameters: i) innodb_rollback_segments = number of rollback_segments to use (default is now 128) dynamic parameter, can be changed anytime. Currently there is little benefit in changing it from the default. Optimisations in the patch. i. Change the O(n) behaviour of trx_rseg_get_on_id() to O(log n) Backported from 5.6. Refactor some of the binary heap code. Create a new include/ut0bh.ic file. ii. Avoid truncating the rollback segments after every purge. Related changes that were moved to a separate patch: i. Purge should not do any flushing, only wait for space to be free so that it only does purging of records unless it is held up by a long running transaction that is preventing it from progressing. ii. Give the purge thread preference over transactions when acquiring the rseg->mutex during commit. This to avoid purge blocking unnecessarily when getting the next rollback segment to purge. Bug #11766501 changes: Add the rseg to the min binary heap under the cover of the kernel mutex and the binary heap mutex. This ensures the ordering of the min binary heap. The two changes have to be committed together because they share the same that fixes both issues. rb://567 Approved by: Inaam Rana.
-
- 21 Feb, 2011 2 commits
-
-
Jorgen Loland authored
UPDATES THE TABLE ENTRIES (formerly 55385) BUG#11764529: MULTI UPDATE+INNODB REPORTS ER_KEY_NOT_FOUND IF A TABLE IS UPDATED TWICE (formerly 57373) If multiple-table update updates a row through two aliases and the first update physically moves the row, the second update will fail to locate the row. This results in different errors depending on storage engine: * MyISAM: Got error 134 from storage engine * InnoDB: Can't find record in 'tbl' None of these errors accurately describe the problem. Furthermore, since MyISAM is non-transactional, the update executed first will be performed while the second will not. In addition, for two equal multiple-table update statements, one could succeed and the other fail based on whether or not the record actually moved or not. This was inconsistent. Two update operations may physically move a row: 1) Update of a column in a clustered primary key 2) Update of a column used to calculate which partition the row belongs to BUG#11764529 is about case 1) above, BUG#11762751 was about case 2). The fix for these bugs is to return with an error if multiple-table update is about to: a) Update a table through multiple aliases, and b) Perform an update that may physically more the row in at least one of these aliases This avoids * partial updates as described for MyISAM above, * provides the same error message that describes the actual problem for all SEs * inconsistent behavior where a statement fails or succeeds based on e.g. the partitioning algorithm of the table.
-
Magnus Blåudd authored
-