The result set for multi-row statements is not the same between STMT and
RBR and among different versions. Thus to avoid test failures, we are not
printing out such result sets. Note, however, that this does not have
impact on coverage and accuracy since the execution is able to continue
without further issues when an error is found on the master and such error
is set to be skipped.
The test started failing following the push for BUG#41541.
Some of the algorithms access bytes beyond the input data
and this can affect up to one byte less than "word size"
which is BITS_SAVED / 8.
Fixed by adding (BITS_SAVED / 8) -1 bytes to buffer size
(i.e. Memory Segment #2) to avoid accessing un-allocated data.
We didn't expect "error: no error", although this is
in fact a legitimate state (if something is erroneous
on the master, but not on the slave, e.g. INSERT fails
on master due to UNIQUE constraint which does not exist
on slave).
We now list the ignore for "0: no error" the same way
as any other ignore; moreover, if no or an empty
--slave-skip-errors is passed at start-up, we show
"OFF" instead of empty list, as intended. (The code
for that was there, but was only run for the empty-
argument case, even if it subsequently tested for
both conditions.)
Followup to r4575 and the fix of Bug#43309 Test main.innodb can't be run twice:
Add an explanatory comment, as suggested by Patrick Crews in the bug report.
RBR was not considering the option --slave-skip-errors.
To fix the problem, we are reporting the ignored ERROR(s) as warnings thus avoiding
stopping the SQL Thread. Besides, it fixes the output of "SHOW VARIABLES LIKE
'slave_skip_errors'" which was showing nothing when the value "all" was assigned
to --slave-skip-errors.
@sql/log_event.cc
skipped rbr errors when the option skip-slave-errors is set.
@sql/slave.cc
fixed the output of for SHOW VARIABLES LIKE 'slave_skip_errors'"
@test-cases
fixed the output of rpl.rpl_idempotency
updated the test case rpl_skip_error
1. Test case was rewritten completely.
2. Test covers 3 cases:
a) do deadlock on slave, wait retries of transaction, unlock slave before lock
timeout;
b) do deadlock on slave and wait error 'lock timeout exceed' on slave;
c) same as b) but if of max relay log size = 0;
3. Added comments inline.
4. Updated result file.
The problem is that a SELECT .. FOR UPDATE statement might open
a table and later wait for a impeding global read lock without
noticing whether it is holding a table that is being waited upon
the the flush phase of the process that took the global read
lock.
The same problem also affected the following statements:
LOCK TABLES .. WRITE
UPDATE .. SET (update and multi-table update)
TRUNCATE TABLE ..
LOAD DATA ..
The solution is to make the above statements wait for a impending
global read lock before opening the tables. If there is no
impending global read lock, the statement raises a temporary
protection against global read locks and progresses smoothly
towards completion.
Important notice: the patch does not try to address all possible
cases, only those which are common and can be fixed unintrusively
enough for 5.0.
Mysql server crashes because unsafe statements warning is wrongly elevated to error,
which is set the error status of Diagnostics_area of the thread in THD::binlog_query().
Yet the caller believes that binary logging shouldn't touch the status, so it will
set the status also later by my_ok(), my_error() or my_message() seperately
according to the execution result of the statement or transaction.
But the status of Diagnostics_area of the thread is allowed to set only once.
Fixed to clear the error wrongly set by binary logging, but keep the warning message.
Altered the test to accommodate the new behavior of max_allowed_packet.
Had to disconnect / reconnect the default connection for the new value to register.
Re-enabled certain parts of the test that were commented out and added
some setup / cleanup code to ensure proper reset of max_allowed_packet at the end of the test.
Re-recorded the .result file to account for changes to the test.
history. This addresses Mantis issue #116.
dict_index_t: Enable the storage of trx_id.
row_prebuilt_t: Make many fields bit-fields to reduce the memory
footprint. Add index_usable.
ha_innobase::change_active_index(): Check if the index is usable and
set prebuilt->index_usable accordingly. Unfortunately, the return
status of this function is ignored by MySQL, and the actual refusal to
use the index must be made in row_search_for_mysql().
row_search_for_mysql(): Return DB_MISSING_HISTORY if
!prebuilt->index_usable.
convert_error_code_to_mysql(): Map DB_MISSING_HISTORY to
HA_ERR_TABLE_DEF_CHANGED.
innodb-index.test: Add a test case where access to a newly created
secondary index must be blocked for old transactions.
rb://100 approved by Heikki Tuuri
Original commentary:
Bug #37348: Crash in or immediately after JOIN::make_sum_func_list
The optimizer pulls up aggregate functions which should be aggregated in
an outer select. At some point it may substitute such a function for a field
in the temporary table. The setup_copy_fields function doesn't take this
into account and may overrun the copy_field buffer.
Fixed by filtering out the fields referenced through the specialized
reference for aggregates (Item_aggregate_ref).
Added an assertion to make sure bugs that cause similar discrepancy
don't go undetected.
- Update testcases funcs_1.is_routines to only query
information_schema.routines about the routines in 'test'
database(where it has created it's routines)
The problem is that XML functions(items) do not reset null_value
before their execution and further item excution may use
null_value value of the previous result.
The fix is to reset null_value.
- Some tests need to modify the server(s) so much that a total restart of all servers are
necessary after test. Make it possible for a test to signal it want mtr.pl to restart
all servers.
Fix Bug#43309 Test main.innodb can't be run twice
Make the innodb mysql-test more flexible by inspecting how much a
variable of interest has changed since the start of the test. Do not
assume the variables have zero values at the start of the test.
Restore the state of INNODB_THREAD_CONCURRENCY to silence this warning:
TEST RESULT TIME (ms)
------------------------------------------------------------
worker[1] Using MTR_BUILD_THREAD 250, with reserved ports 12500..12509
main.innodb [ pass ] 8803
MTR's internal check of the test case 'main.innodb' failed.
This means that the test case does not preserve the state that existed
before the test case was executed. Most likely the test case did not
do a proper clean-up.
This is the diff of the states of the servers before and after the
test case was executed:
mysqltest: Logging to '/tmp/autotest.sh-20090330_033000-5.1.5Hg8CY/mysql-5.1/mysql-test/var/tmp/check-mysqld_1.log'.
mysqltest: Results saved in '/tmp/autotest.sh-20090330_033000-5.1.5Hg8CY/mysql-5.1/mysql-test/var/tmp/check-mysqld_1.result'.
mysqltest: Connecting to server localhost:12500 (socket /tmp/autotest.sh-20090330_033000-5.1.5Hg8CY/mysql-5.1/mysql-test/var/tmp/mysqld.1.sock) as 'root', connection 'default', attempt 0 ...
mysqltest: ... Connected.
mysqltest: Start processing test commands from './include/check-testcase.test' ...
mysqltest: ... Done processing test commands.
--- /tmp/autotest.sh-20090330_033000-5.1.5Hg8CY/mysql-5.1/mysql-test/var/tmp/check-mysqld_1.result 2009-03-30 14:12:31.000000000 +0300
+++ /tmp/autotest.sh-20090330_033000-5.1.5Hg8CY/mysql-5.1/mysql-test/var/tmp/check-mysqld_1.reject 2009-03-30 14:12:41.000000000 +0300
@@ -99,7 +99,7 @@
INNODB_SUPPORT_XA ON
INNODB_SYNC_SPIN_LOOPS 20
INNODB_TABLE_LOCKS ON
-INNODB_THREAD_CONCURRENCY 8
+INNODB_THREAD_CONCURRENCY 16
INNODB_THREAD_SLEEP_DELAY 10000
INSERT_ID 0
INTERACTIVE_TIMEOUT 28800
mysqltest: Result content mismatch
not ok
