Last commit made on 2022-09-28
Get this branch:
git clone -b 10.7

Branch merges

Branch information


Recent commits


MDEV-29570 InnoDB fails to clean bulk buffer when server does rollback operation

- During bulk insert, server detects the error and does rollback
operation. At that time, InnoDB fails to clean up the bulk insert

trx_t::rollback_finish(): Removed the clean up of modified tables
from transaction

trx_t::commit_cleanup(): Free the bulk buffer for bulk insert operation

trx_t::commit(): Check whether modified table wasn't dropped only
for non-dictionary transaction

7c7ac6d... by Marko Mäkelä

Merge 10.6 into 10.7

789f55c... by Marko Mäkelä

MDEV-28701 after-merge fix

Update the result of a ./mtr --ps-protocol test

44fd2c4... by Marko Mäkelä

Merge 10.5 into 10.6

0792aff... by Marko Mäkelä

Merge 10.4 into 10.5

0c0a569... by Marko Mäkelä

Merge 10.3 into 10.4

5dcc56b... by Alexander Barkov

MDEV-29561 SHOW CREATE TABLE produces syntactically incorrect structure

5d9d379... by Marko Mäkelä

MDEV-15020 fixup: Make trx_t::apply_log() truly ATTRIBUTE_COLD

b73c70c... by Daniel Bartholomew <email address hidden>

bump the VERSION

5ab78cf... by Vlad Lesin

MDEV-29515 innodb.deadlock_victim_race is unstable

The test is unstable because 'UPDATE t SET b = 100' latches a page and
waits for 'upd_cont' signal in lock_trx_handle_wait_enter sync point, then
purge requests RW_X_LATCH on the same page, and then 'SELECT * FROM t
WHERE a = 10 FOR UPDATE' requests RW_S_LATCH, waiting for RW_X_LATCH
requested by purge. 'UPDATE t SET b = 100' can't release page latch as
it waits for upd_cont signal, which must be emitted after 'SELECT * FROM
t WHERE a = 10 FOR UPDATE' acquired RW_S_LATCH. So we have a deadlock,
which is resolved by finishing the debug sync point wait by timeout, and
the 'UPDATE t SET b = 100' releases it's record locks rolling back the
transaction, and 'SELECT * FROM t WHERE a = 10 FOR UPDATE' is finished
successfully instead of finishing by lock wait timeout.

The fix is to forbid purging during the test by opening read view in a
separate connection before the first insert into the table.

Besides, 'lock_wait_end' syncpoint is not needed, as it enough to wait
the end of the SELECT execution to let the UPDATE to continue.