(server crash)
Altering a table with fulltext index[es] which use
pluggable fulltext parser may cause server crash
in debug builds.
The problem was that ALTER TABLE code wrongly assigned
fulltext parser name.
Also fixed that altering a table with fulltext index[es]
leave stale fulltext parser locks, which prevent
fulltext parsers from being uninstalled after
ALTER TABLE.
mysql-test/include/have_simple_parser.inc:
Added support for testing simple fulltext parser.
mysql-test/mysql-test-run.pl:
Added support for testing simple fulltext parser.
mysql-test/r/fulltext_plugin.result:
A test case for BUG#39746.
mysql-test/r/have_simple_parser.require:
Added support for testing simple fulltext parser.
mysql-test/t/fulltext_plugin-master.opt:
A test case for BUG#39746.
mysql-test/t/fulltext_plugin.test:
A test case for BUG#39746.
sql/sql_table.cc:
Fixed that alter table wrongly assigns fulltext parser
name. parser_name member is only available during
table creation. When we open existing table we must
get parser_name from plugin_ref, which is handled
by plugin_name() macro.
sql/table.cc:
Moved code that releases fulltext parsers into
free_table_share(). This fixes stale fulltext parser
locks set by ALTER TABLE, which are preventing fulltext
parsers from being uninstalled.
Adding --loose-skip-falcon option to the mysqld options provided by MTR (v2) during mysqld bootstrap in order to avoid plugin (in this case Falcon) initialization of static variables etc. Options --loose-skip-innodb and --loose-skip-ndbcluster were already included.
This will fix Bug#41014 (falcon_bug_39708 fails in pushbuild in 6.0-rpl: "succeeded - should have failed")
in the case of MTR v2 (which currently is available in -rpl branches only).
MTR v1 (e.g. in main 6.0 branch) does not have this problem.
It would be more ideal to remove the --loose-skip-* options and provide a single option disabling all plugin initialization instead, or have bootstrap do this by default. Server modifications are (most likely) needed to be able to do that.
mysql-test/mysql-test-run.pl:
Reintroduced the --loose-skip-falcon bootstrap option used by the previous version of this test runner.
Addition of hander function was_semi_consistent_read
mysql-test/r/partition_innodb_semi_consistent.result:
post push fix for bug#40595
Addition of hander function was_semi_consistent_read
Added test result
mysql-test/t/partition_innodb_semi_consistent-master.opt:
post push fix for bug#40595
Addition of hander function was_semi_consistent_read
Added test opt file
mysql-test/t/partition_innodb_semi_consistent.test:
post push fix for bug#40595
Addition of hander function was_semi_consistent_read
Added test case
sql/ha_partition.cc:
post push fix for bug#40595
Addition of hander function was_semi_consistent_read
The lack of was_semi_consistent_read opened a regression
for bug-31310 when useing a partitioned InnoDB table
A follow-up fix for Bug 38839, which exposed a pre-existing bug in the
autoinc handling.
Detailed revision comments:
r2722 | sunny | 2008-10-04 02:48:04 +0300 (Sat, 04 Oct 2008) | 18 lines
branches/5.1: This bug has always existed but was masked by other errors. The
fix for bug# 38839 triggered this bug. When the offset and increment are > 1
we need to calculate the next value taking into consideration the two
variables. Previously we simply assumed they were 1 particularly offset was
never used. MySQL does its own calculation and that's probably why it seemed
to work in the past. We would return what we thought was the correct next
value and then MySQL would recalculate the actual value from that and return
it to the caller (e.g., handler::write_row()). Several new tests have been
added that try and catch some edge cases. The tests exposed a wrap around
error in MySQL next value calculation which was filed as bug 39828. The tests
will need to be updated once MySQL fix that bug.
One good side effect of this fix is that dict_table_t size has been
reduced by 8 bytes because we have moved the autoinc_increment field to
the row_prebuilt_t structure. See review-board for a detailed discussion.
rb://3
Bug #39438: Testcase for Bug#39436 crashes on 5.1 in fil_space_get_latch
Detailed revision comments:
r2719 | vasil | 2008-10-03 18:17:28 +0300 (Fri, 03 Oct 2008) | 49 lines
branches/5.1:
Fix Bug#39438 Testcase for Bug#39436 crashes on 5.1 in fil_space_get_latch
In ha_innobase::info() - do not try to get the free space for a tablespace
which has been discarded with ALTER TABLE ... DISCARD TABLESPACE or if the
.ibd file is missing for some other reason.
ibd_file_missing and tablespace_discarded are manipulated only in
row_discard_tablespace_for_mysql() and in row_import_tablespace_for_mysql()
and the manipulation is protected/surrounded by
row_mysql_lock_data_dictionary()/row_mysql_unlock_data_dictionary() thus we
do the same in ha_innobase::info() when checking the values of those members
to avoid race conditions. I have tested the code-path with UNIV_DEBUG and
UNIV_SYNC_DEBUG.
rb://20
Reviewed by: Inaam, Calvin
Approved by: Heikki
Bug#38231: Innodb crash in lock_reset_all_on_table() on TRUNCATE + LOCK / UNLOCK
branches/5.1:
Fix Bug#38231 Innodb crash in lock_reset_all_on_table() on TRUNCATE + LOCK / UNLOCK
In TRUNCATE TABLE and discard tablespace: do not remove table-level S
and X locks and do not assert on such locks not being wait locks.
Leave such locks alone.
Approved by: Heikki (rb://14)
Bug #38839: auto increment does not work properly with InnoDB after update
Detailed revision comments:
r2609 | sunny | 2008-08-24 01:19:05 +0300 (Sun, 24 Aug 2008) | 12 lines
branches/5.1: Fix for MySQL Bug#38839. Reset the statement level last
value field in prebuilt. This field tracks the last value in an autoincrement
interval. We use this value to check whether we need to update a table's
AUTOINC counter, if the value written to a table is less than this value
then we avoid updating the table's AUTOINC value in order to reduce
mutex contention. If it's not reset (e.g., after a DELETE statement) then
there is the possibility of missing updates to the table's AUTOINC counter
resulting in a subsequent duplicate row error message under certain
conditions (see the test case for details).
Bug #38839 - auto increment does not work properly with InnoDB after update
Bug #35537: Innodb doesn't increment handler_update and handler_delete
Detailed revision comments:
r2388 | vasil | 2008-03-27 14:02:34 +0200 (Thu, 27 Mar 2008) | 7 lines
branches/5.1:
Swap the order in which mysql_thd, mysql_query_str and *mysql_query_str
are checked for non-NULL.
Suggested by: Marko
r2421 | calvin | 2008-04-24 15:32:30 +0300 (Thu, 24 Apr 2008) | 6 lines
branches/5.1: Fix bug#35537 - Innodb doesn't increment handler_update
and handler_delete
Add the calls to ha_statistic_increment() in ha_innobase::delete_row()
and ha_innobase::update_row().
The test reacted on the way how mtr orders arguments for the server
that are gathered from different source. It appeared that the opt-file
options were parsed before those that supplied to mtr via its command
line. In effect, the opt-file preferences got overriden by the command
line and some tests, like no-threads, were caught by surprise: a test
expects an option value that had been "hardcoded" into its opt-file
but gets another one.
This server options ordering problem exists on in the new rpl trees
mtr. In option of the author of this patch, the opt-file shall be
considered as having the highest preference weight. The opt-file is
merely a part of the header of a test, namely a part that can not be
technically deployed along the test file.
It's unnatural for the test writer to provide both the opt file value
and a guard that guarantees the value will be set on in the run time.
It's logical to provide either one: the option and its value or the
guard.
Fixed with relocating parse of the opt file to be the last among
sources of the sever's options.
A side effect: fixing a small problem of resetting the suite options
at time the opt file starts parsing.
A side effect: main.log_bin_trust_function_creators_func is disabled to
be re-enabled with the fixes for bug#41003 will be merged from the main trees.
mysql-test/lib/mtr_cases.pm:
Relocating parse of the opt file to be the last. This ensure the opt file is the last
provider for the server options so that the opt-file options have the highest preference;
fixing a separate issue of incorrect resetting the suite options for the server;
mysql-test/t/disabled.def:
log_bin_trust_function_creators_func is disabled. Todo: to-reable when fixes for bug#41003
will be merged from the main trees.
The test
1. did not verify that CREATE FUNCTION shall fails in a case of active binlog
and @@log_bin_trust_function_creators is zero if there is no DETERMINISTIC qualifier
and super user privilege;
2. contained an explit warning on that CREATE FUNCTION actually succeeded whereas
it was supposed to fail;
3. did not demand the bin-log be set ON even though it has contained the opt file
explictily setting the name for the binlog file.
Fixed 1-3 with modifying the test accordingly.
mysql-test/r/log_bin_trust_function_creators_func.result:
Bug #41003 changed results.
mysql-test/t/log_bin_trust_function_creators_func-master.opt:
removed unnecessary file, the specificly requested binlog file name was not used in
the test.
mysql-test/t/log_bin_trust_function_creators_func.test:
corrected the test that previously: 1. did not verify that CREATE FUNCTION shall fail
in some cases; 2. contained an explit warning on that CREATE FUNCTION actually
IF(..., CAST(longtext AS UNSIGNED), signed_val)
(was: LEFT JOIN on inline view crashes server)
Select from a LONGTEXT column wrapped with an expression
like "IF(..., CAST(longtext_column AS UNSIGNED), smth_signed)"
failed an assertion or crashed the server. IFNULL function was
affected too.
LONGTEXT column item has a maximum length of 32^2-1 bytes,
at the same time this is a maximum possible length of any
MySQL item. CAST(longtext_column AS UNSIGNED) returns some
unsigned numeric result of length 32^2-1, so the result of
IF/IFNULL function of this number and some other signed number
will have text length of (32^2-1)+1=32^2 (one byte for the
minus sign) - there is integer overflow, and the length is
equal to zero. That caused assert/crash.
CAST AS UNSIGNED function has been modified to limit maximal
length of resulting number to 67 (maximal length of DECIMAL
and two characters for minus sign and dot).
mysql-test/r/func_if.result:
Added test case for bug #40761.
mysql-test/t/func_if.test:
Added test case for bug #40761.
sql/item_func.h:
Bug #40761: Assert on sum function on
IF(..., CAST(longtext AS UNSIGNED), signed_val)
CAST AS UNSIGNED function has been modified to limit maximal
length of resulting number to 67 (maximal length of DECIMAL
and two characters for minus sign and dot).
The test explicitly warned on existence of a bug in its 27th part.
The expected values of prepare and commit counters changed, corrected, by
fixes to bug#40221.
Notice, that binlog does not have to register for a statement with
the statement binlog-format because the statement rollback does not need
to do anything in that mode. It's not so with the ROW format which was
bug#40221 concern.
Fixed with correcting the expected values of the mentioned counters and
explained that with comments in the test.
mysql-test/include/commit.inc:
Removing `Sic' that warned on a bug (The one is bug#40221).
Correcting the expected values of prepare and commit counters due to fixes to bug#40221.
mysql-test/r/commit_1innodb.result:
results changed.
exact number of error. The patch does following:
1) Add new parameter $slave_sql_errno for wait_for_slave_sql_error.inc
2) Add waiting error 1062 (Duplicate PK) for slave SQL thread in test case.
where timeout can happen:
1. Added waiting start/stop slave to make sure that slave works properly.
2. Added cleanup for slave.
3. Updated related result files.
IF(..., CAST(longtext AS UNSIGNED), signed_val)
(was: LEFT JOIN on inline view crashes server)
Select from a LONGTEXT column wrapped with an expression
like "IF(..., CAST(longtext_column AS UNSIGNED), smth_signed)"
failed an assertion or crashed the server. IFNULL function was
affected too.
LONGTEXT column item has a maximum length of 32^2-1 bytes,
at the same time this is a maximum possible length of any
MySQL item. CAST(longtext_column AS UNSIGNED) returns some
unsigned numeric result of length 32^2-1, so the result of
IF/IFNULL function of this number and some other signed number
will have text length of (32^2-1)+1=32^2 (one byte for the
minus sign) - there is integer overflow, and the length is
equal to zero. That caused assert/crash.
The bug has been fixed by the same solution as in the CASE
function implementation.
mysql-test/r/func_if.result:
Added test case for bug #40761.
mysql-test/t/func_if.test:
Added test case for bug #40761.
sql/item_cmpfunc.cc:
Bug #40761: Assert on sum function on
IF(..., CAST(longtext AS UNSIGNED), signed_val)
1. Item_func_case::agg_str_lengths method has been moved
to the Item_func superclass.
2. Item_func_ifnull/Item_func_if::fix_length_and_dec methods
have been updated to calculate max_length, decimals and
unsigned flag like Item_func_case.
sql/item_cmpfunc.h:
Bug #40761: Assert on sum function on
IF(..., CAST(longtext AS UNSIGNED), signed_val)
Item_func_case::agg_str_lengths method has been moved to
the Item_func superclass.
sql/item_func.cc:
Bug #40761: Assert on sum function on
IF(..., CAST(longtext AS UNSIGNED), signed_val)
Item_func_case::agg_str_lengths method has been moved to
the Item_func superclass.
sql/item_func.h:
Bug #40761: Assert on sum function on
IF(..., CAST(longtext AS UNSIGNED), signed_val)
Item_func_case::agg_str_lengths method has been moved to
the Item_func superclass.
Fix parsing of mysql client commands, especially in relation to
single-line comments when --comments was specified.
This is a little tricky, because we need to allow single-line
comments in the middle of statements, but we don't want to allow
client commands in the middle of statements. So in
comment-preservation mode, we go ahead and send single-line
comments to the server immediately when we encounter them on their
own.
This is still slightly flawed, in that it does not handle a
single-line comment with leading spaces, followed by a client-side
command when --comment has been enabled. But this isn't a new
problem, and it is quite an edge condition. Fixing it would require
a more extensive overall of how the mysql client parses commands.
Added KEY_BLOCK_SIZE option to I_S.TABLES.CREATE_OPTIONS field
mysql-test/r/information_schema.result:
test result
mysql-test/t/information_schema.test:
test case
sql/sql_show.cc:
Added KEY_BLOCK_SIZE option to I_S.TABLES.CREATE_OPTIONS field
Removed values with more than 15 significant digits from the test case. Results of
reading/printing such values using system library functions depend on implementation
and thus are not portable.
mysql-test/r/type_float.result:
Removed values with more than 15 significant digits from the test case.
mysql-test/t/type_float.test:
Removed values with more than 15 significant digits from the test case.
