- 24 Jul, 2013 1 commit
-
-
Guilhem Bichot authored
Inside a loop in a stored procedure, we create a partitioned table. The CREATE statement is thus treated as a prepared statement: it is prepared once, and then executed by each iteration. Thus its Lex is reused many times. This Lex contains a part_info member, which describes how the partitions should be laid out, including the partitioning function. Each execution of the CREATE does this, in open_table_from_share (): tmp= mysql_unpack_partition(thd, share->partition_info_str, share->partition_info_str_len, outparam, is_create_table, share->default_part_db_type, &work_part_info_used); ... tmp= fix_partition_func(thd, outparam, is_create_table); The first line calls init_lex_with_single_table() which creates a TABLE_LIST, necessary for the "field fixing" which will be done by the second line; this is how it is created: if ((!(table_ident= new Table_ident(thd, table->s->db, table->s->table_name, TRUE))) || (!(table_list= select_lex->add_table_to_list(thd, table_ident, NULL, 0)))) return TRUE; it is allocated in the execution memory root. Then the partitioning function ("id", stored in Lex -> part_info) is fixed, which calls Item_ident:: fix_fields (), which resolves "id" to the table_list above, and stores in the item's cached_table a pointer to this table_list. The table is created, later it is dropped by another statement, then we execute again the prepared CREATE. This reuses the Lex, thus also its part_info, thus also the item representing the partitioning function (part_info is cloned but it's a shallow cloning); CREATE wants to fix the item again (which is normal, every execution fixes items again), fix_fields () sees that the cached_table pointer is set and picks up the pointed table_list. But this last object does not exist anymore (it was allocated in the execution memory root of the previous execution, so it has been freed), so we access invalid memory. The solution: when creating the table_list, mark that it cannot be cached.
-
- 18 Jul, 2013 2 commits
-
-
Nisha Gopalakrishnan authored
TO DUMP DATA FROM MYSQL-5.6 Merge from mysql-5.1 to mysql-5.5.
-
Nisha Gopalakrishnan authored
TO DUMP DATA FROM MYSQL-5.6 Analysis -------- Dumping mysql-5.6 data using mysql-5.1/mysql-5.5 'myqldump' utility fails with a syntax error. Server system variable 'sql_quote_show_create' which quotes the identifiers is set in the mysqldump utility. The mysldump utility of mysql-5.1/mysql-5.5 uses deprecated syntax 'SET OPTION' to set the 'sql_quote_show_create' option. The support for the syntax is removed in mysql-5.6. Hence syntax error is reported while taking the dump. Fix: --- Changed the 'mysqldump' code to use the syntax 'SET SQL_QUOTE_SHOW_CREATE' to set the 'sql_quote_show_create' option. That syntax is supported on mysql-5.1, mysql-5.5 and mysql-5.6. NOTE: I have not added an mtr test case since it is difficult to simulate the condition. Also the syntax may not be further simplified in the future.
-
- 17 Jul, 2013 2 commits
-
-
sayantan dutta authored
-
sayantan dutta authored
-
- 10 Jul, 2013 2 commits
-
-
Jimmy Yang authored
rb://2582 approved by Inaam
-
Annamalai Gurusami authored
SERIALIZABLE Problem: The documentation claims that WITH CONSISTENT SNAPSHOT will work for both REPEATABLE READ and SERIALIZABLE isolation levels. But it will work only for REPEATABLE READ isolation level. Also, the clause WITH CONSISTENT SNAPSHOT is silently ignored when it is not applicable to the given isolation level. Solution: Generate a warning when the clause WITH CONSISTENT SNAPSHOT is ignored. rb#2797 approved by Kevin. Note: Support team wanted to push this to 5.5+.
-
- 09 Jul, 2013 2 commits
-
-
Murthy Narkedimilli authored
-
murthy.narkedimilli@oracle.com authored
-
- 08 Jul, 2013 1 commit
-
-
hery.ramilison@oracle.com authored
-
- 05 Jul, 2013 1 commit
-
-
Aditya A authored
MULTI-FILE TABLESPACE ANALYSIS -------- When a tablespace has multiple data files, InnoDB fails to open the tablespace. This is because for each ibd file, the first page is checked.But the first page of all ibd file need not be the first page of the tablespace. Only the first page of the tablespace contains the tablespace header. When we check the first page of an ibd file that is not the first page of the tablespace, then the "tablespace flags" is not really available.This was wrongly used to check if a page is corrupt or not. FIX --- Use the tablespace flags only if the page number is 0 in a tablespace. [Approved by Inaam rb#2836 ]
-
- 04 Jul, 2013 1 commit
-
-
Venkata Sidagam authored
WITH UTF8_UNICODE_CI COLLATION Problem Description: When comparing datetime values with strings, the utf8_unicode_ci collation prevents correct comparisons. Consider the below set of queries, it is not showing any results on a table which has tuples that satisfies the query. But for collation utf8_general_ci it shows one tuple. set names utf8 collate utf8_unicode_ci;; select * from lang where dt='1979-12-09'; Analysis: The comparison function is not chosen in case of collation utf8_unicode_ci. In agg_item_set_converter() because the collation state is having "MY_CS_NONASCII" for collation type "utf8_unicode_ci". The conversion of the collation is happening for the date field. And because of that it is unable to pickup proper compare function(i.e CMP_DATE_WITH_STR). Actually the bug is accidentally introduced by the WL#3759 in 5.5. And in 5.6 it is been fixed by the WL#3664. Fix: I have backported the changes from the file strings/ctype-uca.c which are related to "utf8" introduced by the WL#3664. This change helps in choosing the correct comparison function for all the collations of utf8 charset.
-
- 01 Jul, 2013 3 commits
-
-
Tor Didriksen authored
-
Tor Didriksen authored
Cleanup test case (left outfile in data dir)
-
mysql-builder@oracle.com authored
No commit message
-
- 28 Jun, 2013 2 commits
-
-
Georgi Kodinov authored
-
Mattias Jonsson authored
ALTER TABLE ... ALGORITHM= ... STATEMENT The problem was an intermediate buffer of smaller size, which truncated the alter statement. Solved by providing the size of the buffer to be allocated through the function call, instead of using an one-size-fits-all stack buffer inside the function.
-
- 27 Jun, 2013 2 commits
-
-
Balasubramanian Kandasamy authored
-
Balasubramanian Kandasamy authored
Bug16785036 - RPM REQUIRES: MISSING PACKAGES ON RHEL 6 (AND PROBABLY 5) Bug 16878042 - CANNOT KEEP SEVERAL MAJOR VERSIONS OF MYSQL IN THE SAME YUM REPOSITORY
-
- 26 Jun, 2013 3 commits
-
-
Balasubramanian Kandasamy authored
-
Georgi Kodinov authored
Backported the deprecation warnings from WL#6978 to 5.5
-
Annamalai Gurusami authored
Problem: The problem is that explain_filename-t is not printing a test plan as required by the TAP protocol. The test invokes plan(NO_PLAN) but does not invoke exit_status() at the end, where the plan would be printed. Solution: Invoke exit_status() at the end.
-
- 25 Jun, 2013 1 commit
-
-
bin.x.su@oracle.com authored
Straight forward backport. Approved by Jimmy, rb#2656
-
- 24 Jun, 2013 3 commits
-
-
mysql-builder@oracle.com authored
No commit message
-
Sujatha Sivakumar authored
LOAD DATA CAN CAUSE SQL INJECTION Problem: ======= A long SET expression in LOAD DATA is incorrectly truncated when written to the binary log. Analysis: ======== LOAD DATA statements are reconstructed once again before they are written to the binary log. When SET clauses are specified as part of LOAD DATA statement, these SET clause user command strings need to be stored as it is inorder to reconstruct the original user command. At present these strings are stored as part of SET clause item tree's top most Item node's name itself which is incorrect. As an Item::name can be of MAX_ALIAS_NAME (256) size. Hence the name will get truncated to "255". Because of this the rewritten LOAD DATA statement will be terminated incorrectly. When this statment is read back by the mysqlbinlog tool it reads a starting single quote and continuos to read till it finds an ending quote. Hence any statement written post ending quote will be considered as a new statement. Fix: === As name field has length restriction the string value should not be stored in Item::name. A new String list is maintained to store the SET expression values and this list is read during reconstrution.
-
mysql-builder@oracle.com authored
No commit message
-
- 21 Jun, 2013 1 commit
-
-
Tor Didriksen authored
Sys_var_keycache inherits from some variant of Sys_var_integer Instances of Sys_var_keycache are initialized using the KEYCACHE_VAR macro, which takes an offset within st_key_cache. However, the Sys_var_integer CTOR treats the offset as if it was within global_system_variables (hidden within some layers of macros and fuction pointers) The result is that we write arbitrary data to arbitrary locations in memory. This all happens during static initialization of global objects, i.e. before we have even entered the main() function. Bug#12325449 TYPO IN CMAKE/DTRACE.CMAKE Fix typo in dtrace.cmake
-
- 19 Jun, 2013 2 commits
- 18 Jun, 2013 4 commits
-
-
Vasil Dimov authored
DDL AND I_S QUERIES Skip partially created indexes (ones whose name starts with TEMP_INDEX_PREFIX) from stats gathering. Because InnoDB reports HA_INPLACE_ADD_INDEX_NO_WRITE to MySQL, the latter allows parallel execution of ha_innobase::add_index() and ha_innobase::info(). Reviewed by: Inaam (rb:2613)
-
mysql-builder@oracle.com authored
No commit message
-
mysql-builder@oracle.com authored
No commit message
-
mysql-builder@oracle.com authored
No commit message
-
- 17 Jun, 2013 1 commit
-
-
mysql-builder@oracle.com authored
No commit message
-
- 14 Jun, 2013 6 commits
-
-
kevin.lewis@oracle.com authored
IF IT HAS A WRONG COUNT If CHECK TABLE finds that a secondary index contains the wrong number of entries, it used to report an error but not mark the index as corrupt. The error means that the index should be rebuilt, which can be done with ALTER TABLE DROP INDEX and ALTER TABLE ADD INDEX. But just in case the DBA does not pay any attention to the output of CHECK TABLE, the secondary index should be marked as corrupted so that it is not used again. Approved by Inaam in RB:2607
-
Tor Didriksen authored
Backport to 5.5
-
mysql-builder@oracle.com authored
No commit message
-
Tor Didriksen authored
Backport to 5.5 (external Bug#69407 Build warnings with mysql)
-
mysql-builder@oracle.com authored
No commit message
-
Aditya A authored
TO INCONSISTENCY [Merge from 5.1]
-