internal data dictionary
- re-enabled innodb_mysql test;
- added a rule to through away expected warning to mtr_report.pl;
- fixed a test case to produce unique warning.
The get_time_value function is added. It is used to obtain TIME values both
from items the can return time as an integer and from items that can return
time only as a string.
The Arg_comparator::compare_datetime function now uses pointer to a getter
function to obtain values to compare. Now this function is also used for
comparison of TIME values.
The get_value_func variable is added to the Arg_comparator class.
It points to a getter function for the DATE/DATETIME/TIME comparator.
results.
When executing a CREATE EVENT statement with ON COMPLETION NOT PRESERVE
clause (explicit or implicit) and completion date in the past, we do not
create the event. Or, put it differently, we create it and then drop
immediately.
A warning is issued in this case, not an error -- we want to load
successfully old database dumps, and such dumps may contain events
that are no longer valid.
Update the warning text to not imply an erroneous condition.
The Field_newdate::store when storing a DATETIME value was returning the
'value was cut' error even if the thd->count_cuted_fields flag is set to
CHECK_FIELD_IGNORE. This made range optimizr think that there is no
appropriate data in the table and thus to return an empty set.
Now the Field_newdate::store function returns conversion error only if the
thd->count_cuted_fields flag isn't set to CHECK_FIELD_IGNORE.
Added an option to yassl to allow "quiet shutdown" like openssl does. This option causes the SSL libs to NOT perform the close_notify handshake during shutdown. This fixes a hang we experience because we hold a lock during socket shutdown.
Part 2:
Searching fulltext index for a word with boolean mode truncation
operator may cause infinite loop.
The problem was that "smarter index merge" was used with "trunc-words",
which must never happen.
Affects 5.1 only.
Time values were compared by the BETWEEN function as strings. This led to a
wrong result in cases when some of arguments are less than 100 hours and other
are greater.
Now if all 3 arguments of the BETWEEN function are of the TIME type then
they are compared as integers.
causes full table lock on innodb table.
Also fixes Bug#28502 Triggers that update another innodb table
will block on X lock unnecessarily (duplciate).
Code review fixes.
Both bugs' synopses are misleading: InnoDB table is
not X locked. The statements, however, cannot proceed concurrently,
but this happens due to lock conflicts for tables used in triggers,
not for the InnoDB table.
If a user had an InnoDB table, and two triggers, AFTER UPDATE and
AFTER INSERT, competing for different resources (e.g. two distinct
MyISAM tables), then these two triggers would not be able to execute
concurrently. Moreover, INSERTS/UPDATES of the InnoDB table would
not be able to run concurrently.
The problem had other side-effects (see respective bug reports).
This behavior was a consequence of a shortcoming of the pre-locking
algorithm, which would not distinguish between different DML operations
(e.g. INSERT and DELETE) and pre-lock all the tables
that are used by any trigger defined on the subject table.
The idea of the fix is to extend the pre-locking algorithm to keep track,
for each table, what DML operation it is used for and not
load triggers that are known to never be fired.
causing wrong error message in Falcon
An error message about a duplicate key could show a wrong key
value when not all columns of the key were used to select the
rows for update.
Some storage engines return a record with only the selected
columns filled.
This is fixed by re-reading the record with a read_set which
includes all columns of the duplicate key after a duplicate key
error happens and before the error message is printed.
A race condition in the integration between MyISAM and the query cache code
caused the query cache to fail to invalidate itself on concurrently inserted
data.
This patch fix this problem by using the existing handler interface which, upon
each statement cache attempt, compare the size of the table as viewed from the
cache writing thread and with any snap shot of the global table state. If the
two sizes are different the global table size is unknown and the current
statement can't be cached.
SHOW CREATE TABLE or SELECT FROM I_S.
This is the last patch for this bug, which depends on the big
CS patch and was pending.
The problem was that SHOW CREATE statements returned original
queries in the binary character set. That could cause the query
to be unreadable.
The fix is to use original character_set_client when sending
the original query to the client. In order to preserve the query
in mysqldump, 'binary' character set results should be set when
issuing SHOW CREATE statement. If either source or destination
character set is 'binary' , no conversion is performed.
The idea is that since the source character set is no longer
'binary', we fix the destination character set to still produce
valid dumps.
Actually, this testcase will fail generally on all testing platforms.
The bugs come from the inconsistent bitmap between rpl master and slave.
In log_event.cc, the n_bits of m_cols and m_cols_ai are intialized with octal-ceiling
m_width, in fact, their n_bits should be equal to m_width.
Wrong n_bits will cause bitmap_bits_set() get incorrect value in unpack_row()
in rpl_record.cc,
then an assertion in unpack_row() will fail and crash sql thread.
DBUG_ASSERT(null_ptr == row_data + master_null_byte_count);
Meanwhile, because of binlog_prepare_pending_rows_event() changed with correct
m_cols, some results of specific testcases should be updated:
binlog_multi_engine.test
ndb_binlog_multi.test
rpl_ndb_dd_partitions.test
rpl_ndb_log.test
rpl_truncate_7ndb.test
rpl_truncate_7ndb_2.test
In addition, to ensure rows replication correct between master and slave after the patch,
two 'select * from t1' are added in extra/rpl_tests/rpl_log.test, and some testcases include
rpl_log.test, therefore, the results of these testcases should be updated likewise:
rpl_stm_log.test
rpl_row_log.test
rpl_ndb_log.test
rpl_row_log_innodb.test
Totally, results of nine testcases are updated.
