- 09 Sep, 2013 1 commit
-
-
Tor Didriksen authored
Add missing initialization in lex_start()
-
- 06 Sep, 2013 1 commit
-
-
Raghav Kapoor authored
-
- 05 Sep, 2013 2 commits
-
-
Venkata Sidagam authored
FILES SPECIFIED WITH THE BASEDIR OPTION Reverting the patch. Because asked for second review.
-
Nisha Gopalakrishnan authored
DO WHAT YOU EXPECT" Fix info: -------- Backport of the deprecation bug fix (WL#5265) for global variable 'THREAD_CONCURRENCY' from mysql-5.6 to mysql-5.5 Note: With this backport, certain additional deprecation warnings would be reported under error conditions while setting the global/session variables.
-
- 04 Sep, 2013 1 commit
-
-
Neeraj Bisht authored
CONTAINING NULL Problem:- In MySQL, We can obtain the number of distinct expression combinations that do not contain NULL by giving a list of expressions in COUNT(DISTINCT). However rows with NULL values are incorrectly included in the count when loose index scan is used. Analysis:- In case of loose index scan, we check whether the field is null or not and increase the count in Item_sum_count::add(). But there we are checking for the first field in COUNT(DISTINCT), not for every field. This is causing an incorrect result. Solution:- Check all field in Item_sum_count::add(), whether there values are null or not. Then only increment the count. ****** Bug#17222452 - SELECT COUNT(DISTINCT A,B) INCORRECTLY COUNTS ROWS CONTAINING NULL Problem:- In MySQL, We can obtain the number of distinct expression combinations that do not contain NULL by giving a list of expressions in COUNT(DISTINCT). However rows with NULL values are incorrectly included in the count when loose index scan is used. Analysis:- In case of loose index scan, we check whether the field is null or not and increase the count in Item_sum_count::add(). But there we are checking for the first field in COUNT(DISTINCT), not for every field. This is causing an incorrect result. Solution:- Check all field in Item_sum_count::add(), whether there values are null or not. Then only increment the count.
-
- 02 Sep, 2013 1 commit
-
-
Arun Kuruvila authored
SPECIFIED WITH THE BASEDIR OPTION Description: The mysql_plugin client attempts to remove any filename specified to the --basedir option. The problem is that if the filename does not end with a slash, it will attempt to unlink it, which succeeds for files, but not for directories. Analysis: When we are starting mysql_plugin with basedir option and if we are giving path of a file as basedir, it deletes that file. It was because it uses a function my_delete which unlinks the file path given. Fix: As a fix we replace that line using another function my_free, which will only free the pointer which is having that file path.
-
- 01 Sep, 2013 1 commit
-
-
mysql-builder@oracle.com authored
No commit message
-
- 30 Aug, 2013 3 commits
-
-
Igor Solodovnikov authored
Memory Leak in mysql_options() was caused by missing call to my_free() in MYSQL_SET_CLIENT_IP branch. Fixed by adding my_free() to cleanup mysql->options.client_ip value before assigning new value.
-
Igor Solodovnikov authored
-
Igor Solodovnikov authored
Memory Leak in mysql_options() was caused by missing call to my_free() in MYSQL_SET_CLIENT_IP branch. Fixed by adding my_free() to cleanup mysql->options.client_ip value before assigning new value.
-
- 28 Aug, 2013 3 commits
-
-
Raghav Kapoor authored
ERROR HANDLING CODE BACKGROUND: There can be a potential crash due to buffer overrun in SSL error handling code due to missing comma in ssl_error_string[] array in viosslfactories.c. ANALYSIS: Found by code Inspection. FIX: Added the missing comma in SSL error handling code in ssl_error_string[] array in viosslfactories.c.
-
Raghav Kapoor authored
ERROR HANDLING CODE BACKGROUND: There can be a potential crash due to buffer overrun in SSL error handling code due to missing comma in ssl_error_string[] array in viosslfactories.c. ANALYSIS: Found by code Inspection. FIX: Added the missing comma in SSL error handling code in ssl_error_string[] array in viosslfactories.c.
-
Neeraj Bisht authored
Problem:- Second execution of prepared statement for query with parameter in limit clause, causes an assert when using connectors (e.g., Connector C). Analysis:- In prepared statement, LIMIT parameters can be specified using '?' markers. Value for the parameter can be supplied while executing the prepared statement. Passing string, float or double values for LIMIT clause works well from command-line client. That's because, while setting the LIMIT parameter value from a user-variable, the value is converted to integer value. However, when prepared statement is executed from other interfaces as J connectors, or C applications etc, the value for the parameters are sent to the server with execute command. Each item in command has value and the data TYPE. So, while setting parameter values from this log, value is set to all the parameters with the same data type as passed. Here, we have the logic to convert the value to change the state and item_type if it is part of LIMIT parameter and its item_type is not INT. But when we reset this parameter we save the item_type but change state. So on second execution we have old item_type but our state has been changed, which make us to use string type variable in Item_param::query_str_val(). This cause an assert. Fix: Instead of checking the item_type of the parameter, check for the state of the parameter. As state value are reset everytime we execute the statement.
-
- 27 Aug, 2013 1 commit
-
-
balasubramanian.kandasamy@oracle.com authored
-
- 26 Aug, 2013 3 commits
-
-
Hery Ramilison authored
-
hery.ramilison@oracle.com authored
-
Dmitry Lenev authored
ER_LOCK_WAIT_TIMEOUT". The problem was that after changes caused by fix bug 14188793 "DEADLOCK CAUSED BY ALTER TABLE DOEN'T CLEAR STATUS OF ROLLBACKED TRANSACTION"/ bug 17054007 "TRANSACTION IS NOT FULLY ROLLED BACK IN CASE OF INNODB DEADLOCK implicit rollback of transaction which occurred on ER_LOCK_DEADLOCK (and ER_LOCK_WAIT_TIMEOUT if innodb_rollback_on_timeout option was set) didn't start new transaction in @@autocommit=1 mode. Such behavior although consistent with behavior of explicit ROLLBACK has broken expectations of users and backward compatibility assumptions. This patch fixes problem by reverting to starting new transaction in 5.5/5.6. The plan is to keep new behavior in trunk so the code change from this patch is to be null-merged there.
-
- 23 Aug, 2013 8 commits
-
-
Praveenkumar Hulakund authored
"SHOW PROCESSLIST" Follow up path, addressing pb2 test failure.
-
Praveenkumar Hulakund authored
-
mysql-builder@oracle.com authored
No commit message
-
Neeraj Bisht authored
Problem:- In a Procedure, when we are comparing value of select query with IN clause and they both have different collation, cause error on first time execution and assert second time. procedure will have query like set @x = ((select a from t1) in (select d from t2));<---proc1 sel1 sel2 Analysis:- When we execute this proc1(first time) While resolving the fields of user variable, we will call Item_in_subselect::fix_fields while will resolve sel2. There in Item_in_subselect::select_transformer, we evaluate the left expression(sel1) and store it in Item_cache_* object (to avoid re-evaluating it many times during subquery execution) by making Item_in_optimizer class. While evaluating left expression we will prepare sel1. After that, we will put a new condition in sel2 in Item_in_subselect::select_transformer() which will compare t2.d and sel1(which is cached in Item_in_optimizer). Later while checking the collation in agg_item_collations() we get error and we cleanup the item. While cleaning up we cleaned the cached value in Item_in_optimizer object. When we execute the procedure second time, we have condition for sel2 and while setup_cond(), we can't able to find reference item as it is cleanup while item cleanup.So it assert. Solution:- We should not cleanup the cached value for Item_in_optimizer object, if we have put the condition to subselect.
-
Neeraj Bisht authored
Problem:- In a Procedure, when we are comparing value of select query with IN clause and they both have different collation, cause error on first time execution and assert second time. procedure will have query like set @x = ((select a from t1) in (select d from t2));<---proc1 sel1 sel2 Analysis:- When we execute this proc1(first time) While resolving the fields of user variable, we will call Item_in_subselect::fix_fields while will resolve sel2. There in Item_in_subselect::select_transformer, we evaluate the left expression(sel1) and store it in Item_cache_* object (to avoid re-evaluating it many times during subquery execution) by making Item_in_optimizer class. While evaluating left expression we will prepare sel1. After that, we will put a new condition in sel2 in Item_in_subselect::select_transformer() which will compare t2.d and sel1(which is cached in Item_in_optimizer). Later while checking the collation in agg_item_collations() we get error and we cleanup the item. While cleaning up we cleaned the cached value in Item_in_optimizer object. When we execute the procedure second time, we have condition for sel2 and while setup_cond(), we can't able to find reference item as it is cleanup while item cleanup.So it assert. Solution:- We should not cleanup the cached value for Item_in_optimizer object, if we have put the condition to subselect.
-
mysql-builder@oracle.com authored
No commit message
-
mysql-builder@oracle.com authored
No commit message
-
Ashish Agarwal authored
in 5.5, 5.6, 5.7.
-
- 22 Aug, 2013 2 commits
-
-
Balasubramanian Kandasamy authored
-
Balasubramanian Kandasamy authored
-
- 21 Aug, 2013 9 commits
-
-
Sneha Modi authored
THAN LOCALHOST This is a test bug and the explanation for the behaviour can be found on the bug page.Modifying the select to select user where user!=root for the line where failure is encountered on machines with no hostname other than the localhost.
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
compressed pages After loading a compressed-only page in buf_page_get_gen() we allocate a new block for decompression. The problem is that the compressed page is neither buffer-fixed nor I/O-fixed by the time we call buf_LRU_get_free_block(), so it may end up being evicted and returned back as a new block. buf_page_get_gen(): Temporarily buffer-fix the compressed-only block while allocating memory for an uncompressed page frame. This should prevent this form of the infinite loop, which is more likely with a small innodb_buffer_pool_size. rb#2511 approved by Jimmy Yang, Sunny Bains
-
Praveenkumar Hulakund authored
"SHOW PROCESSLIST" Merging from 5.1 to 5.5
-
Praveenkumar Hulakund authored
"SHOW PROCESSLIST" Analysis: ---------- The problem here is, if one connection changes its default db and at the same time another connection executes "SHOW PROCESSLIST", when it wants to read db of the another connection then there is a chance of accessing the invalid memory. The db name stored in THD is not guarded while changing user DB and while reading the user DB in "SHOW PROCESSLIST". So, if THD.db is freed by thd "owner" thread and if another thread executing "SHOW PROCESSLIST" statement tries to read and copy THD.db at the same time then we may endup in the issue reported here. Fix: ---------- Used mutex "LOCK_thd_data" to guard THD.db while freeing it and while copying it to processlist.
-
- 20 Aug, 2013 3 commits
-
-
Balasubramanian Kandasamy authored
-
Balasubramanian Kandasamy authored
-
Dmitry Lenev authored
STATUS OF ROLLBACKED TRANSACTION" and bug #17054007 - "TRANSACTION IS NOT FULLY ROLLED BACK IN CASE OF INNODB DEADLOCK". The problem in the first bug report was that although deadlock involving metadata locks was reported using the same error code and message as InnoDB deadlock it didn't rollback transaction like the latter. This caused confusion to users as in some cases after ER_LOCK_DEADLOCK transaction could have been restarted immediately and in some cases rollback was required. The problem in the second bug report was that although InnoDB deadlock caused transaction rollback in all storage engines it didn't cause release of metadata locks. So concurrent DDL on the tables used in transaction was blocked until implicit or explicit COMMIT or ROLLBACK was issued in the connection which got InnoDB deadlock. The former issue has stemmed from the fact that when support for detection and reporting metadata locks deadlocks was added we erroneously assumed that InnoDB doesn't rollback transaction on deadlock but only last statement (while this is what happens on InnoDB lock timeout actually) and so didn't implement rollback of transactions on MDL deadlocks. The latter issue was caused by the fact that rollback of transaction due to deadlock is carried out by setting THD::transaction_rollback_request flag at the point where deadlock is detected and performing rollback inside of trans_rollback_stmt() call when this flag is set. And trans_rollback_stmt() is not aware of MDL locks, so no MDL locks are released. This patch solves these two problems in the following way: - In case when MDL deadlock is detect transaction rollback is requested by setting THD::transaction_rollback_request flag. - Code performing rollback of transaction if THD::transaction_rollback_request is moved out from trans_rollback_stmt(). Now we handle rollback request on the same level as we call trans_rollback_stmt() and release statement/ transaction MDL locks.
-
- 19 Aug, 2013 1 commit
-
-
mysql-builder@oracle.com authored
No commit message
-