- 26 Jun, 2013 1 commit
-
-
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 7 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]
-
Aditya A authored
TO INCONSISTENCY PROBLEM -------- When we drop a partitoned table , we first gather the information about partitions in the table from the table_name.par file and store it in an internal data structure.Then we delete this file and the data in the table. If the server crashes after deleting the file,then after recovering we cannot access the table .Even we cannot drop the table ,because drop algorithm requires par file to read the partition information. FIX --- 1. We move the part of deleting par file after deleting all the table data from the storage egine. 2. During drop operation if we detect that the par file is missing then we delete the .frm file,since there is no way of recovering without par file. [Approved by Mattias rb#2576 ]
-
- 13 Jun, 2013 1 commit
-
-
Annamalai Gurusami authored
ON DELETION ORDER Problem: When a InnoDB index page is under-filled, we will merge it with either the left sibling node or the right sibling node. But this checking is incorrect. When the left sibling node is available, even if merging is not possible with left sibling node, we do not check for the possibility of merging with the right sibling node. Solution: If left sibling node is available, and merging with left sibling node is not possible, then check if merge with right sibling node is possible. rb#2506 approved by jimmy & ima.
-
- 12 Jun, 2013 2 commits
-
-
Sivert Sorumgard authored
CAN LEAD TO MISSING TABLES Overview -------- If the FOREIGN_KEY_CHECKS system variable is set to 0, it is possible to break a foreign key constraint by changing the type or character set of the foreign key column, or by dropping the foreign key index (without carrying out corresponding changes on another table in the relationship). If we subsequently set FOREIGN_KEY_CHECKS to 1 and execute ALTER TABLE involving the COPY algorithm on such a table, the following happens: 1) If ALTER TABLE does not contain a RENAME clause, the attempt to install the new version of the table instead of the old one will fail due to the fact that the inconsistency will be detected. An attempt to revert the partially executed alter table operation by restoring the old table definition will fail as well due to FOREIGN_KEY_CHECKS == 1. As a result, the table being altered will be lost. 2) If ALTER TABLE contains the RENAME clause, the inconsistency will not be detected (most probably due to other bugs). But if an attempt to install the new version of the table fails (for example, due to a failure when updating triggers associated with the table), reverting the partially executed alter table by restoring the old table definition will fail too. So the table being altered might be lost as well. Suggested fix ------------- The suggested fix is to temporarily unset the option bit representing FOREIGN_KEY_CHECKS when the old table definition is restored while reverting the partially executed operation.
-
mysql-builder@oracle.com authored
No commit message
-
- 10 Jun, 2013 3 commits
-
-
Murthy Narkedimilli authored
-
Murthy Narkedimilli authored
-
Murthy Narkedimilli authored
-
- 07 Jun, 2013 2 commits
-
-
Olav Sandstaa authored
Revert fix since it caused mtr tests to not run in pushbuild.
-
sayantan dutta authored
-
- 06 Jun, 2013 1 commit
-
-
Murthy Narkedimilli authored
-
- 05 Jun, 2013 1 commit
-
-
ramesh.maddali@oracle.com authored
-
- 04 Jun, 2013 1 commit
-
-
murthy.narkedimilli@oracle.com authored
-
- 03 Jun, 2013 1 commit
-
-
sayantan dutta authored
-
- 29 May, 2013 1 commit
-
-
Sreedhar S authored
-
- 24 May, 2013 4 commits
-
-
Maitrayi Sabaratnam authored
Bug#13116514 - CREATE LOGFILE GROUP INITIAL_SIZE & UNDO_BUFFER_SIZE FAILS Fixing parser to accept the syntax: to give a size with suffix 'M', eg. undo_buffer_size=10M (M for mega bytes), in 'create logfile group' command.
-
Marko Mäkelä authored
i_s_innodb_buffer_page_get_info(): Do not read the buffer block frame contents of read-fixed blocks, because it may be invalid or uninitialized. When we are going to decompress or read a block, we will put it into buf_pool->page_hash and buf_pool->LRU, read-fix the block and release the mutexes for the duration of the reading or decompression. rb#2500 approved by Jimmy Yang
-
Venkatesh Duggirala authored
BY BINLOG_KILLED_SIMULATE.TEST Merging fix from mysql-5.1
-
Venkatesh Duggirala authored
BY BINLOG_KILLED_SIMULATE.TEST 'mysqbinlog' tool creates a temporary file while preparing LOAD DATA QUERY. These files needs to be deleted at the end of the test script otherwise these files are left out in the daily-run machines, causing "no space on device issues" Fix: Delete them at the end of these test scripts 1) execute mysqlbinlog with --local-load option to create these files in a specified tmpdir 2) delete the tmpdir at the end of the test script
-
- 23 May, 2013 3 commits
-
-
Chaithra Gopalareddy authored
-
Chaithra Gopalareddy authored
STRING CONVERSION FUNCTIONS Problem: While executing the prepared statement, user variable is set to memory which would be freed at the end of execution. If the statement is executed again, valgrind throws error when accessing this pointer. Analysis: 1. First time when Item_func_set_user_var::check is called, memory is allocated for "value" to store the result. (In the call to copy_if_not_alloced). 2. While sending the result, Item_func_set_user_var::check is called again. But, this time, its called with "use_result_field" set to true. As a result, we call result_field->val_str(&value). 3. Here memory allocated for "value" gets freed. And "value" gets set to "result_field", with "str_length" being that of result_field's. 4. In the call to JOIN::cleanup, result_field's memory gets freed as this is allocated in a chunk as part of the temporary table which is needed to execute the query. 5. Next time, when execute of the same statement is called, "value" will be set to memory which is already freed. Valgrind error occurs as "str_length" is positive (set at Step 3) Note that user variables list is stored as part of the Lex object in set_var_list. Hence the persistance across executions. Solution: Patch for Bug#11764371 fixed in mysql-5.6+ fixes this problem as well.So backporting the same. In the solution for Bug#11764371, we create another object of user_var and repoint it to temp_table's field. As a result while deleting the alloced buffer in Step 3, since the cloned object does not own the buffer, deletion will not happen. So at step 5 when we execute the statement second time, the original object will be used and since deletion did not happen valgrind will not complain about dangling pointer.
-
Chaithra Gopalareddy authored
-