ha_statistic_increment for rpl_temporary
Problem: in some cases master send a special event to reconnecting
slave to keep slave's temporary tables (see #17284) and they still
have references to the "old" SQL slave thread and use them to access
thread's data.
Fix: set temporary tables thread references to the actual SQL slave
thread in such cases.
Adds --general-log-file, --slow-query-log-file command-
line options to match system variables of the same names.
Deprecates --log, --log-slow-queries command-line option
and log, log_slow_queries system-variables for v7.0; they
are superseded by general_log/general_log_file and
slow_query_log/slow_query_log_file, respectively.
"Trigger fired multiple times leads to gaps in auto_increment sequence".
The bug was that if a trigger fired multiple times inside a top
statement (for example top-statement is a multi-row INSERT,
and trigger is ON INSERT), and that trigger inserted into an auto_increment
column, then gaps could be observed in the auto_increment sequence,
even if there were no other users of the database (no concurrency).
It was wrong usage of THD::auto_inc_intervals_in_cur_stmt_for_binlog.
Note that the fix changes "class handler", I'll tell the Storage Engine API team.
MyISAM blocks index usage for bulk insert into zero-records tables.
See ha_myisam::start_bulk_insert() lines from
...
if (file->state->records == 0 ...
...
That causes problems for partition engine when some partitions have records some not
as the engine uses same access method for all partitions.
Now partition engine doesn't call index_first/index_last
for empty tables.
per-file comments:
mysql-test/r/partition.result
Bug#38005 Partitions: error with insert select.
test result
mysql-test/t/partition.test
Bug#38005 Partitions: error with insert select.
test case
sql/ha_partition.cc
Bug#38005 Partitions: error with insert select.
ha_engine::index_first and
ha_engine::index_last not called for empty tables.
Adds --general_log_file, --slow_query_log_file command-
line options to match system variables of the same names.
Deprecates --log, --log-slow-queries command-line options
and log, log_slow_queries system-variables for v7.0; they
are superseded by general_log/general_log_file and
slow_query_log/slow_query_log_file, respectively.
problems are located in the sql_partition.cc where functions calculation
partition_id don't expect error returned from item->val_int().
Fixed by adding checks to these functions.
Note - it tries to fix more problems than just the reported bug.
per-file comments:
modified:
mysql-test/r/partition.result
Bug#38083 Error-causing row inserted into partitioned table despite error
test result
mysql-test/t/partition.test
Bug#38083 Error-causing row inserted into partitioned table despite error
test case
sql/opt_range.cc
Bug#38083 Error-causing row inserted into partitioned table despite error
get_part_id() call fixed
sql/partition_info.h
Bug#38083 Error-causing row inserted into partitioned table despite error
get_subpart_id_func interface changed.
sql/sql_partition.cc
Bug#38083 Error-causing row inserted into partitioned table despite error
various functions calculationg partition_id and subpart_id didn't expect
an error returned from item->val_int(). Error checks added.
The problem was that the test was trying to obtain a lock on
a table in one connection without ensuring that a insert which
was executed in another connection had released the lock on the
same table.
The solution is to add a dummy select query after the insert to
ensure that the table is unlocked and closed by the time it tries
to lock it again. This is enough to prevent test failures described
in the bug report. As an extra safety measure, concurrent inserts
are disabled.
Remove comments that calculated the Table_locks_immediate. This
value is not tested anymore and it's calculation did not reflect
the actual value.
The test failed originally -- did not reset binlogging - for the reason
identified by bug@15580.
However it never can be run on the embedded platfrom for yet another cause -
the embedded can not KILL query.
Comments added to the test particularly relating `reset master'
to the mentioned bug.
The grep expression that finds a running "mysqld" program fails if the
"mysqld_safe" is running with the same PID.
Now, excise "ps" output that has the word " grep" or "mysqld_safe" in
it, to be a little more certain that the matched process is not a false
positive hit. This will fail when the path to mysqld contains either
of those two names, which should be acceptable.
Additionally, some text to search could be truncated if very long.
Expand the number of lines "ps" emits.
