mirror of
https://github.com/MariaDB/server.git
synced 2025-01-19 05:22:25 +01:00
ade71b2522
It was a forgotten rw_unlock(), due to the deadlock detector feature (so bug was only in 5.1-maria, not 6.0-maria). mysql-test/suite/maria/r/maria3.result: result, all fine mysql-test/suite/maria/t/maria3.test: Test of BUG#39697: two scenarios (transactional tables, and non-transactional table but dynamic row format so still taking the rwlock) where the hang happened. t2 added by this test was masked by a temporary table created earlier in the test, which we forgot to drop. storage/maria/ha_maria.cc: use new macro storage/maria/ma_blockrec.c: use new macro storage/maria/ma_commit.c: use new macro storage/maria/ma_init.c: putting address of dummy_transaction_object in --debug trace can be useful storage/maria/ma_open.c: use new macro storage/maria/ma_write.c: if local_lock_tree is true, we have acquired keyinfo->root_lock so need to release it before "goto err". A pair of assertions so that our usage of TrIDs is kept sensible. storage/maria/maria_def.h: A macro so that changes of MARIA_HA::trn can be tracked with --debug. It helped to understand in what cases, in maria_write(), we could have !(info->dup_key_trid == info->trn->trid) && !share->now_transactional (answer: ALTER TABLE adding UNIQUE index on transactional table). |
||
|---|---|---|
| .. | ||
| binlog | ||
| bugs | ||
| funcs_1 | ||
| funcs_2 | ||
| im | ||
| jp | ||
| large_tests | ||
| manual | ||
| maria | ||
| ndb | ||
| ndb_team | ||
| parts | ||
| rpl | ||
| rpl_ndb | ||
| stress | ||