(This is attempt at fix#2) (re-commit with fixed typo)
- Moved the testcase from partition_test to partition_innodb.test where it can really work.
- Made ordered index scans over ha_partition tables to satisfy ROR property for
the case where underlying table uses extended keys.
The problem was that a big record was allocated on the stack, which casued stack to run out.
Fixed by using my_safe_alloca() instead of my_alloca() when allocating records.
Now only records <= 16384 are allocated on the stack.
mysql-test/r/stack-crash.result:
Added test case
mysql-test/t/stack-crash.test:
Added test case
storage/maria/ma_blockrec.c:
Use my_safe_alloca() instead of my_alloca()
storage/maria/ma_dynrec.c:
Use my_safe_alloca() instead of my_alloca()
storage/maria/maria_def.h:
Added MARIA_MAX_RECORD_ON_STACK
storage/maria/maria_pack.c:
Use my_safe_alloca() instead of my_alloca()
MDEV-5555: Incorrect index_merge on BTREE indices
- In ha_partition, make ordered index reads return rows in rowid order
when index columns are the same.
Deadlock happened due to mixed lock order.
CREATE/DROP function: wrlock(THR_LOCK_udf) -> lock(LOCK_open)
SELECT from view: lock(LOCK_open) -> rdlock(THR_LOCK_udf)
Fixed CREATE/DROP function so that LOCK_open does not intersect with
wrlock(THR_LOCK_udf).
10.0 is not affected: it doesn't hold LOCK_open while opening view.
(mainly by backporting 5.5. changes)
mysql-test/suite/maria/t/distinct.test:
Remove the test that requires SSL. One test case for a bug is enough.
sql/scheduler.cc:
make it the same as in 5.5
storage/innodb_plugin/row/row0mysql.c:
make it the same as in 5.5
storage/innodb_plugin/row/row0sel.c:
make it the same as in 5.5
storage/xtradb/row/row0mysql.c:
make it the same as in 5.5
storage/xtradb/row/row0sel.c:
make it the same as in 5.5
ACCEPTED BUT PARSED INCORRECTLY
When we are setting the value in a system variable,
We can set it like
set sys_var="Iden1.Iden2"; //1
set sys_var='Iden1.Iden2'; //2
set sys_var=Iden1.Iden2; //3
set sys_var=.ident1.ident2; //4
set sys_var=`Iden1.Iden2`; //5
While parsing, for case 1(when ANSI_QUOTES is enable) and 2,
we will take as string literal(we will make item of type Item_string).
for case 3 & 4, taken as Item_field, where Iden1 is a table name and
iden2 is a field name.
for case 5, again Item_field type, where iden1.iden2 is taken as
field name.
Now in case 1, when we are assigning some value to system variable
(which can take string or enumerate type data), we are setting only
field part.
This means only iden2 value will be set for system variable. This
result in wrong result.
Solution:
(for string type) We need to Document that we are not allowed to set
system variable which takes string as identifier, otherwise result
in unexpected behaviour.
(for enumerate type)
if we pass iden1.iden2, we will give an error ER_WRONG_TYPE_FOR_VAR
(Incorrect argument type to variable).
mysql-test/suite/sys_vars/t/general_log_file_basic.test:
Earlier we used to give ER_WRONG_VALUE_FOR_VAR error, but in the patch of
(Bug32748-Inconsistent handling of assignments to general_log_file/slow_query_log_file)
they quoted this line.But i am not able to find any relation of this with the changes of
patch. So i think We should give error in this case.
mysql-test/suite/sys_vars/t/slow_query_log_file_basic.test:
Earlier we used to give ER_WRONG_VALUE_FOR_VAR error, but in the patch of
(Bug32748-Inconsistent handling of assignments to general_log_file/slow_query_log_file)
they quoted this line.But i am not able to find any relation of this with the changes of
patch. So i think We should give error in this case.
Problem was that we used cache_table in some cases where it was not initialized
mysql-test/r/func_group.result:
Added test case
mysql-test/t/func_group.test:
Added test case
sql/item.cc:
Don't use cached_table if not set
sql/item_sum.cc:
Don't use cached_table
mysql-test/suite/innodb/r/row_lock.result:
Test case for MDEV-5629
mysql-test/suite/innodb/t/row_lock.test:
Test case for MDEV-5629
sql/filesort.cc:
Don't call unlock_row() in case of errors
Problem:
In the clustered index, when an update operation is done the overall
scenario (after rb#4479) is as follows:
1. Delete mark the old record that is to be updated.
2. The old record disowns the blobs.
3. Insert the new record into clustered index.
4. For non-updated blobs, new record must own it. Verified by assert.
5. For non-updated blobs, in new record marked as inherited.
Scenario involving DB_LOCK_WAIT:
If step 3 times out, then we will skip 1 and 2 and will continue from
step 3. This skipping is achieved by the UPD_NODE_INSERT_BLOB state.
In this case, step 4 is not correct. Because of step 1, the new
record need not own the blobs. Hence the assert failure.
Solution:
The assert in step 4 is removed. Instead code is added to ensure that
the record owns the blob.
Note:
This is a regression caused by rb#4479.
rb#4571 approved by Marko
AUTO_INCREMENT_INCREMENT
Problem:
=======
When auto_increment_increment system variable decreases,
immediate next value of auto increment column is not affected.
Solution:
========
Get the previous inserted value of auto increment column by
subtracting the previous auto_increment_increment from next
auto increment value. After that calculate the current autoinc value
using newly changed auto_increment_increment variable.
Approved by Sunny [rb#4394]
The field JOIN::select_lex->where should be updated after the call
of remove_eq_conds() in the function make_join_statistics(). This
matters for subselects.
Problem:
The function row_upd_changes_ord_field_binary() is used to decide whether to
use row_upd_clust_rec_by_insert() or row_upd_clust_rec(). The function
row_upd_changes_ord_field_binary() does not make use of charset information.
Based on binary comparison it decides that r1 and r2 differ in their ordering
fields.
In the function row_upd_clust_rec_by_insert(), an update is done by delete +
insert. These operations internally make use of cmp_dtuple_rec_with_match()
to compare records r1 and r2. This comparison takes place with the use of
charset information.
This means that it is possible for the deleted record to be reused in the
subsequent insert. In the given scenario, the characters 'a' and 'A' are
considered equal in the my_charset_latin1. When this happens, the ownership
information of externally stored blobs are not correctly handled.
Solution:
When an update is done by delete followed by insert, disown the relevant
externally stored fields during the delete marking itself (within the same
mtr). If the insert succeeds, then nothing with respect to blob ownership
needs to be done. If the insert fails, then the disown done earlier will be
removed when the operation is rolled back.
rb#4479 approved by Marko.
on server shutdown after SELECT with CONVERT_TZ
It's wrong to return my_empty_string from val_str().
Removing my_empty_string. Using make_empty_result() instead.
INSTALL PLUGIN
There was mixed lock order between LOCK_plugin, LOCK_global_system_variables
and LOCK_system_variables_hash. This patch ensures that write-lock on
LOCK_system_variables_hash doesn't intersect with LOCK_plugin.
Fixed by moving initialization/deinitialization of plugin options from
plugin_add()/plugin_del() to plugin_initialize()/plugin_deinitalize().
So that plugin options are handled without protection of LOCK_plugin.
