SHOW PROCESSLIST might see a thread that started executing a query *after*
processlist has started. Don't show a negative or huge wrapped-around query execution time.
mysql_derived_merge_for_insert() should not be called for views or derived tables which are not put (directly or via other views) in main SELECT_LEX "join list".
with query cache, charset ucs2 and collation ucs2_unicode_ci
@ mysql-test/r/ctype_ucs2_query_cache.result
@ mysql-test/t/ctype_ucs2_query_cache-master.opt
@ mysql-test/t/ctype_ucs2_query_cache.test
Adding tests
@ sql/sql_cache.cc
Fixing not to use default_character_set->state_map,
which can point to a non-ASCII character set (utc2, utf16, utf32)
and thus have state_map undefined.
get_mm_leaf function can store all sorts of spatial features in
one type of field it receives from an Item_field.
So we just allow that by setting the type of this field to GEOMETRY.
per-file comments:
mysql-test/r/gis-rtree.result
result updated
mysql-test/t/gis-rtree.test
test case added.
sql/opt_range.cc
set geom_type=GEOMETRY if we got Field_geom.
Fixed some failing tests
mysql-test/mysql-test-run.pl:
Removed warning from mysql-test-run
mysql-test/r/create.result:
Updated result
mysql-test/r/log_slow.result:
Fixed failing test
mysql-test/suite/funcs_1/r/is_columns_is.result:
Updated result
mysql-test/suite/funcs_1/r/processlist_priv_no_prot.result:
Updated result
mysql-test/suite/funcs_1/r/processlist_val_no_prot.result:
Updated result
mysql-test/t/log_slow.test:
Ensure variables are properly reset at end of test
sql/sql_show.cc:
Fixed max length for user names
This could happen when using Aria for internal temporary files (default case) and using DISTINCT.
_ma_scan_restore_block_record() didn't work correctly if there was rows inserted, updated or deleted on the handler
between calls to _ma_scan_remember_block_record() and _ma_scan_restore_block_record().
The effect was that some DISTINCT queries that used remove_dup_with_compare() could fail.
.bzrignore:
Ignore sql_yacc.hh
mysql-test/suite/maria/r/distinct.result:
Test case for MDEV-4280
mysql-test/suite/maria/t/distinct.test:
Test case for MDEV-4280
mysql-test/t/mysql.test:
Fixed test suite (we could get error -1 in some cases)
sql/sql_select.cc:
Break loop if restart_rnd_next() gives an error
storage/maria/ha_maria.cc:
scan_restore_pos() can return disk fault error.
storage/maria/ma_blockrec.c:
_ma_scan_remember_block_record() did incorrectly update scan.dir instead of scan_save.dir .
_ma_scan_restore_block_record() didn't work correctly if there was rows inserted,updated or deleted on the handler
between calls to _ma_scan_remember_block_record() and _ma_scan_restore_block_record().
Fixed by adding counters for row changes and reading the current scan page if changes had been made.
storage/maria/ma_blockrec.h:
scan_restore_pos() can return disk fault error.
storage/maria/ma_delete.c:
Increment row_changes
storage/maria/ma_scan.c:
scan_restore_pos() can return disk fault error.
storage/maria/ma_update.c:
Increment row_changes
storage/maria/ma_write.c:
Increment row_changes
storage/maria/maria_def.h:
scan_restore_pos() can return disk fault error.
MDEV-4489 "Replication of big5, cp932, gbk, sjis strings makes wrong values on slave"
has been fixed.
Problem:
String constants of some Asian charsets (big5,cp932,gbk,sjis)
can have backslash '\' (0x5C) in the second byte of multi-byte characters.
Replicating of such constants using the standard '\'-escaping is dangerous.
Therefore, constants of these charsets are replicated using hex notation:
INSERT INTO t1 (a) VALUES (0x815C);
However, 0xHHHH constants do not work well in some cases,
because they can behave as strings and as numbers, depending on context
(for example, depending on the data type of the column in an INSERT statement).
This SQL script was not replicated correctly with statement-based replication:
SET NAMES gbk;
PREPARE STMT FROM 'INSERT INTO t1 (a) VALUES (?)';
SET @a = '1';
EXECUTE STMT USING @a;
The INSERT statement was replicated as:
INSERT INTO t1 (a) VALUES (0x31);
'1' was correctly converted to the number 1 on master.
But the 0x31 constant was treated as number 49 on slave.
Fix:
1. Binary log now uses X'HHHH' instead of 0xHHHH constants.
2. The X'HHHH' constants now work always as strings, in all contexts.
This is the SQL standard compliant behaviour.
After the fix, the above statement is replicated as:
INSERT INTO t1 (a) VALUES (X'31');
X'31' is treated as string '1' on slave, and is correctly converted to 1.
modified:
@ mysql-test/r/ctype_cp932_binlog_stm.result
@ mysql-test/r/select.result
@ mysql-test/r/select_jcl6.result
@ mysql-test/r/select_pkeycache.result
@ mysql-test/r/user_var-binlog.result
@ mysql-test/r/varbinary.result
@ mysql-test/suite/binlog/r/binlog_stm_ctype_ucs.result
@ mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result
@ mysql-test/suite/rpl/r/rpl_charset_sjis.result
@ mysql-test/suite/rpl/r/rpl_mdev382.result
@ mysql-test/suite/rpl/t/rpl_charset_sjis.test
@ mysql-test/t/ctype_cp932_binlog_stm.test
@ mysql-test/t/select.test
@ mysql-test/t/varbinary.test
Adding and updating tests
@ sql/item.cc
@ sql/item.h
@ sql/sql_yacc.yy
@ sql/sql_lex.cc
Splitting the implementations of X'HH' and 0xHH constants into two
separate classes. Fixing the parser to distinguish the two syntaxes.
@ sql/log_event.cc
Using X'HH' instead of 0xHH for binary logging for string constants
of the "dangerous" charsets.
@ sql/sql_string.h
Adding a helped method String::append_hex().
Now we only execute the innermost of them (the most relevant).
The solution was to add a 'handled' marker to MYSQL_ERROR and mark all elements for which we have executed a condition handler.
When searching for new conditions, we will ignore any marked element.
.bzrignore:
Ignore error message file
mysql-test/r/sp.result:
Added testcase for continue handlers.
mysql-test/t/sp.test:
Added testcase for continue handlers.
sql/sp_head.cc:
Mark errors for which we will excute a handler as 'handled'
Ignore already handled warnings/errors
sql/sql_error.cc:
Add 'handled' argument to MYSQL_ERROR, so that we can mark the errors/warnings we have handled.
sql/sql_error.h:
Add 'handled' argument to MYSQL_ERROR, so that we can mark the errors/warnings we have handled.
- Call tmp_having->update_used_tables() *before* we have call JOIN::cleanup().
Making the call after join::cleanup() is not allowed, because subquery
predicate items walk parent join's JOIN_TAB structures. Which can be
invalidated by JOIN::cleanup().
When iterating over a list of conditions using List_iterator
the function remove_eq_conds should skip all predicates that
replace a condition from the list. Otherwise it can come to
an infinite recursion.
<non-nullable datatime field> IS NULL in outer joins with
that in inner joins.
Previously such condition was transformed into the condition
<non-nullable datatime field> = 0 unless the field belonged
to an inner table of an outer join. In this case the predicate
was interpreted as for any other field.
Now if the field in the predicate <non-nullable datatime field> IS NULL
belongs to an inner table of an outer join the predicate is
transformed into the disjunction
<non-nullable datatime field> = 0 OR <non-nullable datatime field> IS NULL.
This is fully compatible with the semantics of such predicates in 5.5.
- When restore_prev_nj_state() is called for the table that is
the last remaining child of a nested join, do not leave that
nested join's bit in join->cur_embedding_map.
- make multi_delete::initialize_tables() take into account that the JOIN structure may have
semi-join nests (which are not fully initialized when this function is called, they have
tab->table=NULL which caused the crash)
- Also checked multi_update::initialize_tables(): it has a different logic and needed no fixing.
This bug was the result of incompleteness of the patch for bug mdev-4177.
When an OR condition is simplified to a single conjunct it is merged
into the embedding AND condition. Multiple equalities are also merged,
and any field item involved in those equality should acquire a pointer
to a the multiple equality formed by this merge.
The function make_join_statistics checks whether eq_ref access uses only
constant expressions, and, if this is the case the function performs
constant row substitution. The code of this check must take into account
hidden components of extended secondary keys.
The official Debian Wheezy MySQL packages have versions like 5.5.30+dfsg-xxx.
Such version is larger than 5.5.30-yyy, so apt prefers it.
So use instead 5.5.30+maria-yyy, which is larger and can be pulled in
automatically by apt.
Also included are a couple of fixes for test failures in buildbot.
fulltext search was initialized for all MATCH ... AGAINST items
at the end of the JOIN::optimize(). But since 5.3 derived tables
are initialized lazily on first use, very late in the sub_select().
Skip Item_func_match::init_search initialization if the corresponding
table isn't open yet; repeat fulltext initialization for all
not-yet-initialized MATCH ... AGAINST items after creating derived tables.
init join->top_join_tab_count to be in sync with join->join_tab=stat,
otherwise a query can be killed in-between and join_tab's won't be deleted
(JOIN::cleanup won't call JOIN_TAB::cleanup)
Analysis:
The reason for the inefficent plan was that Item_subselect::is_expensive()
didn't detect the special case when a subquery was optimized, but had no
join plan because it either has no table, or its tables have been optimized
away, or the optimizer detected that the result set is empty.
Solution:
Identify the special cases above in the Item_subselect::is_expensive(),
and consider such degenerate subqueries inexpensive.
This bug was introduced by the patch for WL#3220.
If the memory allocated for the tree to store unique elements
to be counted is not big enough to include all of them then
an external file is used to store the elements.
The unique elements are guaranteed not to be nulls. So, when
reading them from the file we don't have to care about the null
flags of the read values. However, we should remove the flag
at the very beginning of the process. If we don't do it and
if the last value written into the record buffer for the field
whose distinct values needs to be counted happens to be null,
then all values read from the file are considered to be nulls
and are not counted in.
The fix does not remove a possible null flag for the read values.
Rather it just counts the values in the same way it was done
before WL #3220.
