WIP: MDEV-17603 REPLACE and INSERT…ON DUPLICATE KEY UPDATE are deadlock-prone
Implement an alternative fix for the bug whose original fix
mysql/mysql-server@c93b0d9a972cb6f98fd445f2b69d924350f9128a
in MySQL 5.7.4 caused problems.
This is based on
mysql/mysql-server@e0e4bacddf421550baca3578bc0db13693874fdb
in MySQL 5.7.26.
When performing a rollback to the start of the current row
operation in REPLACE or INSERT...ON DUPLICATE KEY UPDATE
we were not maintaining serializability, because we would
release implicit locks that could already have been acquired
for some of the indexes.
undo_node_t::convert_impl_to_expl(): Convert an implicit lock
to an explicit one during a partial rollback.
row_insert_for_mysql(): Set trx->duplicates=ULINT_UNDEFINED
for rolling back the current row operation. This will allow
undo_node_t::convert_impl_to_expl() to be effective only
for this use case, not for other scenarios, such as
rolling back to the start of the statement, or
ROLLBACK TO SAVEPOINT.
FIXME: Neither innodb.auto_increment_dup,log-bin nor the
upstream fix (which we did not add) innodb.iodku pass.
While the undo_node_t::convert_impl_to_expl() is working
as intended, what happens in innodb.auto_increment_dup,log-bin
is that the newly created explicit record lock for the record
heap number 6 on the PRIMARY key root page (3) will be released
when that record is deleted moments later, with the following
stack trace:
The idea might work with predicate locks, which we do not have.
This entire scenario could also be fixed by MDEV-16232, which
could allow the entire operation to be protected with page latches.
Bug #29021730 CRASHING INNOBASE_COL_CHECK_FK WITH FOREIGN KEYS
PROBLEM
-------
Function innodb_base_col_setup_for_stored() was skipping to store
the base column information for a generated column if the base column
was a "STORED" generated column. This later causes a crash in function
innoabse_col_check_fk() where it says that a generated columns depends
upon two base columns ,but there is information on only one of them.
There was a explicit check barring the stored columns being stored,
which is wrong because the documentation says that a generated stored
column can be a part of a generated column.
FIX
----
Store the information of base column if it is a stored generated column.
Adapt the test case from
mysql/mysql-server@2bbbcddd903626c84c610dd2ed82cc22ee4d6cde
(MySQL 5.7.26).
06ec56f...
by
Sachin Agarwal <email address hidden>
Bug #27850600 INNODB ASYNC IO ERROR HANDLING IN IO_EVENT
Problem:
io_getevents() - read asynchronous I/O events from the completion
queue. For each IO event, the res field in io_event tells whether IO
event is succeeded or not. To see if the IO actually succeeded we
always need to check event.res (negative=error,
positive=bytesread/written).
LinuxAIOHandler::collect() doesn't check event.res value for each event.
which leads to incorrect value in n_bytes for IO context (or IO Slot).
