When analyzing the possible index use cases the server was re-using an internal structure.
This is wrong, as this internal structure gets updated during the analysis.
Fixed by making a copy of the internal structure for every place it needs to be used.
Also stopped the generation of empty SEL_TREE structures that unnecessary
complicate the analysis.
mysql-test/r/index_merge.result:
Bug#37943: test case
mysql-test/t/index_merge.test:
Bug#37943: test case
sql/opt_range.cc:
Bug#37943:
- Make copy constructors for SEL_TREE and sub-structures and use them when OR-ing trees.
- don't generate empty SEL_TREEs. Return NULL instead.
Re-enabling failing test case because server logs were lost in pushbuild, so we need to run it again.
mysql-test/suite/rpl/t/disabled.def:
Re-enabling failing test case because server logs were lost in pushbuild, so we need to run it again.
Link with mtmalloc on Solaris as it is done in our release builds.
Replace deprecated flag with the newer option as already done in
other scripts.
BUILD/compile-solaris-amd64-forte:
Link to mtmalloc and replace deprecated flag.
BUILD/compile-solaris-amd64-forte-debug:
Replace deprecated flag.
BUILD/compile-solaris-sparc:
Link to mtmalloc.
BUILD/compile-solaris-sparc-forte:
Link to mtmalloc
Post-merge bug fix: lock_type is a enumeration type and not a bit mask.
sql/sql_cache.cc:
Check for lock type explicitly. Also err on the safe side and
invalidate the query cache for any write lock.
Server created "arc" directories inside database directories and
maintained there useless copies of .frm files.
Creation and renaming procedures of those copies as well as
creation of "arc" directories has been discontinued.
Removal procedure has been kept untouched to be able to
cleanup existent database directories by the DROP DATABASE
query. Also view renaming procedure has been updated to remove
these directories.
sql/parse_file.cc:
Fixed bug #17823: 'arc' directories inside database directories.
View/table creation and renaming procedures maintained
backup copies of .frm files. Those copies are unused yet,
so this feature was incomplete and unnecessary.
1. Unwanted code has been hidden by FRM_ARCHIVE ifdefs
(the FRM_ARCHIVE macro is not defined).
2. Renaming procedure has been modified to remove obsolete
"arc" directories.
sql/parse_file.h:
Fixed bug #17823: 'arc' directories inside database directories.
The "thd" parameter has been added to the rename_in_schema_file()
function.
sql/sql_db.cc:
Fixed bug #17823: 'arc' directories inside database directories.
Scope of the mysql_rm_arc_files() function has been changed to
global for use from the parse_file.cc file.
sql/sql_view.cc:
Fixed bug #17823: 'arc' directories inside database directories.
Added the "thd" argument to rename_in_schema_file() calls.
JOIN for the subselect wasn't cleaned if we came upon an error
during sub_select() execution. That leads to the assertion failure
in close_thread_tables()
part of the 6.0 code backported
per-file comments:
mysql-test/r/sp-error.result
Bug#37949 Crash if argument to SP is a subquery that returns more than one row
test result
mysql-test/t/sp-error.test
Bug#37949 Crash if argument to SP is a subquery that returns more than one row
test case
sql/sp_head.cc
Bug#37949 Crash if argument to SP is a subquery that returns more than one row
lex->unit.cleanup() call added if not substatement
The problem is that when statement-based replication was enabled,
statements such as INSERT INTO .. SELECT FROM .. and CREATE TABLE
.. SELECT FROM need to grab a read lock on the source table that
does not permit concurrent inserts, which would in turn be denied
if the source table is a log table because log tables can't be
locked exclusively.
The solution is to not take such a lock when the source table is
a log table as it is unsafe to replicate log tables under statement
based replication. Furthermore, the read lock that does not permits
concurrent inserts is now only taken if statement-based replication
is enabled and if the source table is not a log table.
include/thr_lock.h:
Introduce yet another lock type that my get upgraded depending
on the binary log format. This is not a optimal solution but
can be easily improved later.
mysql-test/r/log_tables.result:
Add test case result for Bug#34306
mysql-test/suite/binlog/r/binlog_stm_row.result:
Add test case result for Bug#34306
mysql-test/suite/binlog/t/binlog_stm_row.test:
Add test case for Bug#34306
mysql-test/t/log_tables.test:
Add test case for Bug#34306
sql/lock.cc:
Assert that TL_READ_DEFAULT is not a real lock type.
sql/mysql_priv.h:
Export new function.
sql/mysqld.cc:
Remove using_update_log.
sql/sql_base.cc:
Introduce function that returns the appropriate read lock type
depending on how the statement is going to be replicated. It will
only take a TL_READ_NO_INSERT log if the binary is enabled and the
binary log format is statement-based and the table is not a log table.
sql/sql_parse.cc:
Remove using_update_log.
sql/sql_update.cc:
Use new function to choose read lock type.
sql/sql_yacc.yy:
The lock type is now decided at open_tables time. This old behavior was
actually misleading as the binary log format can be dynamically switched
and this would not change for statements that have already been parsed
when the binary log format is changed (ie: prepared statements).
In order to improve the performance when replicating to partitioned
myisam tables with row-based format, the number of rows of current
rows log event is estimated and used to setup storage engine for bulk
inserts.
mysql-test/lib/mtr_cases.pl:
forward port the algorithm to check if a binlog format is supported
mysql-test/mysql-test-run.pl:
Don't use dynamic setting of binlog format - does not work
A stored procedure involving substrings could crash the server on certain
platforms because of invalid memory reads.
During storing the new blob-field value, the cached value's address range
overlapped that of the new field value. This caused problems when the
cached value storage was reallocated to provide access for a new
characater set representation. The patch checks the address ranges, and if
they overlap, the new field value is copied to a new storage before it is
converted to the new character set.
mysql-test/r/sp.result:
Added result set
mysql-test/t/sp.test:
Added test case
sql/field.cc:
The source and destination address ranges of a character conversion must not overlap or the 'from' address will be invalidated as the temporary value-
object is re-allocated to fit the new character set.
sql/field.h:
Added comments
and
Bug#33555: Group By Query does not correctly aggregate partitions
Backport of bug-33257 which is the same bug.
read_range_*() calls was not passed to the partition handlers,
but was translated to index_read/next family calls.
Resulting in duplicates rows and wrong aggregations.
mysql-test/r/partition_range.result:
Bug#30573: Ordered range scan over partitioned tables returns some rows twice
Updated result file
mysql-test/t/partition_range.test:
Bug#30573: Ordered range scan over partitioned tables returns some rows twice
Re-enabled the test
sql/ha_partition.cc:
Bug#30573: Ordered range scan over partitioned tables returns some rows twice
backport of bug-33257, correct handling of read_range_* calls,
without converting them to index_read/next calls
sql/ha_partition.h:
Bug#30573: Ordered range scan over partitioned tables returns some rows twice
backport of bug-33257, correct handling of read_range_* calls,
without converting them to index_read/next calls
The fix for bug 31887 was incomplete : it assumes that all the
field types returned by the IS_NUM macro are descendants of
Item_num and tries to zero-fill the values before doing constant
substitution with such fields when they are compared to constant string
values.
The only exception to this is Field_timestamp : it's in the IS_NUM
macro, but is not a descendant of Field_num.
Fixed by excluding timestamp fields (Field_timestamp) when zero-filling
when converting the constant to compare with to a string.
Note that this will not exclude the timestamp columns from const
propagation.
mysql-test/r/compare.result:
Bug #39353: test case
mysql-test/t/compare.test:
Bug #39353: test case
sql/item.cc:
Bug #39353: don't zero-fill timestamp fields when const propagating
to a string : they'll be converted to a string in a date/time format
and not as an integer.
