revision-id: monty@askmonty.org-20140211120313-z158i1sdlxxeotgl
committer: Michael Widenius <monty@askmonty.org>
message:
Enable rpl_row_create_table (no reason to keep this disabled anymore)
Still fails (in --ps), no reason to enable it if it is not fixed.
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
Problem: While printing the Server version, mysql client
doesn't check for the buffer overflow in a
String variable.
Solution: Used a different print function which checks the
allocated length before writing into the string.
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]
Problem:
It was reported that on Debian and KFreeBSD platforms, i386 architecture
machines certain SSL tests are failing. main.ssl_connect rpl.rpl_heartbeat_ssl
rpl.rpl_ssl1 rpl.rpl_ssl main.ssl_cipher, main.func_encrypt were the tests that
were reportedly failing (crashing). The reason for the crashes are said to be
due to the assembly code of yaSSL.
Solution:
There was initially a workaround suggested i.e., to enable
-DTAOCRYPT_DISABLE_X86ASM flag which would prevent the crash, but at an expense
of 4X reduction of speed. Since this was unacceptable, the fix was the
functions using assembly, now input variables from the function call using
extended inline assembly on GCC instead of relying on direct assembly code.
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.