diff options
| author | Dmitry Lenev <dlenev@mysql.com> | 2009-12-30 20:53:30 +0300 |
|---|---|---|
| committer | Dmitry Lenev <dlenev@mysql.com> | 2009-12-30 20:53:30 +0300 |
| commit | 236539b47160a384901533fc41c6793bb5241e0b (patch) | |
| tree | 8db2608b4c8fb2a523f143d1b99effb2fd74b32e /sql/log_event_old.cc | |
| parent | cd6fbffc38bb1c90a81e23c00f0a0fd042d39030 (diff) | |
| download | mariadb-git-236539b47160a384901533fc41c6793bb5241e0b.tar.gz | |
Implementation of simple deadlock detection for metadata locks.
This change is supposed to reduce number of ER_LOCK_DEADLOCK
errors which occur when multi-statement transaction encounters
conflicting metadata lock in cases when waiting is possible.
The idea is not to fail ER_LOCK_DEADLOCK error immediately when
we encounter conflicting metadata lock. Instead we release all
metadata locks acquired by current statement and start to wait
until conflicting lock go away. To avoid deadlocks we use simple
empiric which aborts waiting with ER_LOCK_DEADLOCK error if it
turns out that somebody is waiting for metadata locks owned by
this transaction.
This patch also fixes bug #46273 "MySQL 5.4.4 new MDL: Bug#989
is not fully fixed in case of ALTER".
The bug was that concurrent execution of UPDATE or MULTI-UPDATE
statement as a part of multi-statement transaction that already
has used table being updated and ALTER TABLE statement might have
resulted of loss of isolation between this transaction and ALTER
TABLE statement, which manifested itself as changes performed by
ALTER TABLE becoming visible in transaction and wrong binary log
order as a consequence.
This problem occurred when UPDATE or MULTI-UPDATE's wait in
mysql_lock_tables() call was aborted due to metadata lock
upgrade performed by concurrent ALTER TABLE. After such abort all
metadata locks held by transaction were released but transaction
silently continued to be executed as if nothing has happened.
We solve this problem by changing our code not to release all
locks in such case. Instead we release only locks which were
acquired by current statement and then try to reacquire them
by restarting open/lock tables process. We piggyback on simple
deadlock detector implementation since this change has to be
done anyway for it.
Diffstat (limited to 'sql/log_event_old.cc')
| -rw-r--r-- | sql/log_event_old.cc | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/sql/log_event_old.cc b/sql/log_event_old.cc index 942396fc3da..0f6f4d1d0e5 100644 --- a/sql/log_event_old.cc +++ b/sql/log_event_old.cc @@ -1506,7 +1506,7 @@ int Old_rows_log_event::do_apply_event(Relay_log_info const *rli) */ thd->binlog_flush_pending_rows_event(false); TABLE_LIST *tables= rli->tables_to_lock; - close_tables_for_reopen(thd, &tables); + close_tables_for_reopen(thd, &tables, NULL); uint tables_count= rli->tables_to_lock_count; if ((error= open_tables(thd, &tables, &tables_count, 0))) |