This patch corrects a bug involving a LOAD DATA INFILE operation on a
transactional table. It corrects a problem in the error handler by moving
the transactional table check and autocommit_or_rollback operation to the
end of the error handler.
The problem was an assert was thrown after the operation completed. The
assert found a non-sunk event in the transaction cache. The events in the
transaction cache were added after commit_or_rollack and thereafter nothing
removed them.
An additional test case was added to detect this
condition.
---
Merge pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build-work-vanilla-building
into pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.1-build-work-vanilla-building
---
Fix test cases to pass for a plain ./configure && make build. This includes disabling two test cases when certain features are not present in the server. We're not losing coverage from this because these features are usually present, and disabling them here only serves the purpose to make the test cases work in the unlikely case that they aren't.
---
fixes
(Removes some warnings about UNIX_TIMESTAMP from the slave.err logs)
Marked federated_server as a '--big-test'
Change error in net_clear to 'Note', as it interfered with mysql-test-run.
Adding an event that can be used to denote that an incident occured
on the master. The event can be used to denote a gap in the replication
stream, but can also be used to denote other incidents.
In addition, the injector interface is extended with functions to
generate an incident event. The function will also rotate the binary
log after generating an incident event to get a fresh binary log.
There was hanging at binlog_commit by a thread executing autocommit query.
The hang appeared to be due to an overly condtion for early return
from binlog_commit introduced by bug#20265 fix.
Fixed with reverting the logic back to 5.0 version.
field does not work
Fix to prevent MyISAM from reading data from NULL BLOB.
Fix to make record comparison independent of values of unused bits in
record.
Updating binlog positions in tests.
1. Fixes within the testscripts (affects rpl_ddl.test and rpl_ndb_ddl.test)
- slave connection is only an observer (-> AUTOCOMMIT = 0)
This removes the problem with the hanging test around DROP DATABASE (NDB). The hanging test around DROP DATABASE is a difference to InnoDB/MyISAm behaviour but fare
away of a clear bug. IMHO this behaviour does not violate the SQL standard and should be therefore simply accepted.
- removal of wrong comments
- CREATE/DROP TEMPORARY TABLE must not cause implicit commit of the current transaction.
NDB behaves here correct and InnoDB/Falcon wrong.
- Add a missing connection slave
- Reenable the test rpl_ndb_ddl.
2. Disable rpl_ddl.test because of Bug#26418.
3. Reenable rpl_ndb_ddl.test
4. Improvements (affect rpl_ddl.test and rpl_ndb_ddl.test)
- Better + extended comments which should prevent that somebody accidently destroys the logics of the test
- Replace SELECT's printing comments by "--echo" (decreases the number of auxiliary SQL commands)
- Remove the need for include/rpl_stmt_seq2.inc (was mostly redundant to rpl_stmt_seq.inc)
- Remove extra/rpl_tests/rpl_ndb_ddl.test (corrected extra/rpl_tests/rpl_ddl.test is sufficient)
- Shift assignment of values to $show_binlog, $manipulate (variables useful for debugging) into the toplevel scripts
- The temporary tables get now their storage engine from the variable $temp_engine_type. (more deterministic testing conditions)
- Add additional protocol line if the connection is switched (was partially missing)
- Add two DML commands for comparison purposes
With this patch, statements that change metadata (in the mysql database)
is logged as statements, while normal changes (e.g., using INSERT, DELETE,
and/or UPDATE) is logged according to the format in effect.
The log tables (i.e., general_log and slow_log) are not replicated at all.
With this patch, the following statements are replicated as statements:
GRANT, REVOKE (ALL), CREATE USER, DROP USER, and RENAME USER.
1)
BUG#25507 "multi-row insert delayed + auto increment causes
duplicate key entries on slave" (two concurrrent connections doing
multi-row INSERT DELAYED to insert into an auto_increment column,
caused replication slave to stop with "duplicate key error" (and
binlog was wrong), and BUG#26116 "If multi-row INSERT
DELAYED has errors, statement-based binlogging breaks" (the binlog
was not accounting for all rows inserted, or slave could stop).
The fix is that: in statement-based binlogging, a multi-row INSERT
DELAYED is silently converted to a non-delayed INSERT.
This is supposed to not affect many 5.1 users as in 5.1, the default
binlog format is "mixed", which does not have the bug (the bug is
only with binlog_format=STATEMENT).
We should document how the system delayed_insert thread decides of
its binlog format (which is not modified by this patch):
this decision is taken when the thread is created
and holds until it is terminated (is not affected by any later change
via SET GLOBAL BINLOG_FORMAT). It is also not affected by the binlog
format of the connection which issues INSERT DELAYED (this binlog
format does not affect how the row will be binlogged).
If one wants to change the binlog format of its server with SET
GLOBAL BINLOG_FORMAT, it should do FLUSH TABLES to be sure all
delayed_insert threads terminate and thus new threads are created,
taking into account the new format.
2)
BUG#24432
"INSERT... ON DUPLICATE KEY UPDATE skips auto_increment values".
When in an INSERT ON DUPLICATE KEY UPDATE, using
an autoincrement column, we inserted some autogenerated values and
also updated some rows, some autogenerated values were not used
(for example, even if 10 was the largest autoinc value in the table
at the start of the statement, 12 could be the first autogenerated
value inserted by the statement, instead of 11). One autogenerated
value was lost per updated row. Led to exhausting the range of the
autoincrement column faster.
Bug introduced by fix of BUG#20188; present since 5.0.24 and 5.1.12.
This bug breaks replication from a pre-5.0.24/pre-5.1.12 master.
But the present bugfix, as it makes INSERT ON DUP KEY UPDATE
behave like pre-5.0.24/pre-5.1.12, breaks replication from a
[5.0.24,5.0.34]/[5.1.12,5.1.15]
master to a fixed (5.0.36/5.1.16) slave! To warn users against this when
they upgrade their slave, as agreed with the support team, we add
code for a fixed slave to detect that it is connected to a buggy
master in a situation (INSERT ON DUP KEY UPDATE into autoinc column)
likely to break replication, in which case it cannot replicate so
stops and prints a message to the slave's error log and to SHOW SLAVE
STATUS.
For 5.0.36->[5.0.24,5.0.34] replication or 5.1.16->[5.1.12,5.1.15]
replication we cannot warn as master
does not know the slave's version (but we always recommended to users
to have slave at least as new as master).
As agreed with support, I have asked for an alert to be put into
the MySQL Network Monitoring and Advisory Service.
3) note that I'll re-enable rpl_insert_id as soon as 5.1-rpl gets
the changes from the main 5.1.
does not work): Changing packed row format to only include null bits
for those columns that are present in the row as well as writing BIT
columns in a storage engine-independent format.
The change in row format is incompatible with the previous format and a
slave will not be able to read the new events.
The test uses show binlog event which is not deterministic due to the single insert delayed
query can generate up to number of inserted rows row-events pair (table_map + Write_row)
The solution is to leave the current binlogging behaviour as it is and change
the test as spliting arguments of insert delayed query. Note, that such fix was applied
earlier for binlog_insert_delayed.test :
https://intranet.mysql.com/secure/apps/irclog.php?channel=22&start_time=2006-09-27
There are no tests with insert delayed and show binlog events combination requiring
this fix.
Field_bit::set_default() did not check the bit_len, hence used the undefined
bit_ptr, causing a crash. The patch adds a check that bit_len > 0 before
following the bit_ptr.
Bug#23831 deadlock not noticed
RBR bug in that when replicated msta (multi-statement-trans-action) deadlocks
with a local at write row event or gets timed-out, the event handler did not return
the correct error code.
Wrong error code stops slave sql thread instead of to proceed with
rollback and replay.
The correct code is typed in error log and stored for error handling rotine
to conduct rollback and replay of the transaction. The handling for the rbr
remains the same as for the sbr events.
Particularly, timed-out transaction still is rolled back - look at the related bugs.
