- QUICK_INDEX_MERGE_SELECT deinitializes its rnd_pos() scan when it reaches EOF, but we
need to make the deinitialization in QUICK_INDEX_MERGE_SELECT destructor also. This is because
certain execution strategies can stop scanning without reaching EOF, then then try to do a full
table scan on this table. Failure to deinitialize caused the full scan to use (already empty)
table->sort and produce zero records.
compiled --with-debug, due to bug 39828, "autoinc wraps around when offset and
increment > 1". This change should be reverted when that bug is fixed (and a
a few other minor changes to the test as described in comments).
Static disabled plugins|engines and dynamic plugins which installed but disabled
are not visible in I_S PLUGINS|ENGINES tables because they are not stored into
global plugin array.
The fix: add such plugins|engines to plugin array with PLUGIN_IS_DISABLED status.
I_S.ENGINES 'Transactions', 'XA', 'Savepoints' fields have NULL value in this case.
(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.
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.
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.
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.
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).
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.
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.
