The bug was a side effect of WL#5030 (fix header files) and
WL#5161 (CMake).
The problem was that CMake-generated config.h (and my_config.h
as a copy of it) had a header guard. GNU autotools-generated
[my_]config.h did not. During WL#5030 the order of header files
was changed, so the following started to happen (using GNU autotools,
in embedded server):
- my_config.h included, defining HAVE_OPENSSL
- my_global.h included, un-defining HAVE_OPENSSL
- zlib.h included, including config.h,
defining HAVE_OPENSSL again.
The fix is to change the order of header file, moving zlib.h
to the top of the header list. More proper fix would be to wrap
unguarded auto-generated [my_]config.h by guarded non-generated
header file.
Splitting the kernel mutex at once is a complex task, several mutexes will
be factored out of it. This is one of the easier ones. This mutex sits below
the kernel mutex and is used by the threads infra-structure. It is important
for the multi-threaded purge because for multi-threaded purge we will need
to activate and use InnoDB task queue and query thread scheduling code.
rb://285
transaction
BUG#52616 Temp table prevents switch binlog format from STATEMENT to ROW
Before the WL#2687 and BUG#46364, every non-transactional change that happened
after a transactional change was written to trx-cache and flushed upon
committing the transaction. WL#2687 and BUG#46364 changed this behavior and
non-transactional changes are now written to the binary log upon committing
the statement.
A binary log event is identified as transactional or non-transactional through
a flag in the Log_event which is set taking into account the underlie storage
engine on what it is stems from. In the current bug, this flag was not being
set properly when the DROP TEMPORARY TABLE was executed.
However, while fixing this bug we figured out that changes to temporary tables
should be always written to the trx-cache if there is an on-going transaction.
Otherwise, binlog events in the reversed order would be produced.
Regarding concurrency, keeping changes to temporary tables in the trx-cache is
also safe as temporary tables are only visible to the owner connection.
In this patch, we classify the following statements as unsafe:
1 - INSERT INTO t_myisam SELECT * FROM t_myisam_temp
2 - INSERT INTO t_myisam_temp SELECT * FROM t_myisam
3 - CREATE TEMPORARY TABLE t_myisam_temp SELECT * FROM t_myisam
On the other hand, the following statements are classified as safe:
1 - INSERT INTO t_innodb SELECT * FROM t_myisam_temp
2 - INSERT INTO t_myisam_temp SELECT * FROM t_innodb
The patch also guarantees that transactions that have a DROP TEMPORARY are
always written to the binary log regardless of the mode and the outcome:
commit or rollback. In particular, the DROP TEMPORARY is extended with the
IF EXISTS clause when the current statement logging format is set to row.
Finally, the patch allows to switch from STATEMENT to MIXED/ROW when there
are temporary tables but the contrary is not possible.
newly introduced metadata locks.
Previously the behavior was deterministic and if several LOCKs were
waiting the first one of them was released by UNLOCK (in chronological
order).
Now (with MDLs) the behavior is undefined and since we do not know in
what order to --reap the connections we simply disconnect them without
reaping.
Merge r6915:6992 from branches/innodb+multipbp (i.e.: all the changes
made since it's creation)
This also reverts r6930 to branches/innodb+ because a different
solution for that issue is already present in innodb+multibp which
is being merged.
After this commit branches/innodb+multibp should be discarded
and this branch should become our main development tree.
------------------------------------------------------------------------
r6915 | sbains | 2010-03-31 07:33:43 +0300 (Wed, 31 Mar 2010) | 1 line
Changed paths:
A /branches/innodb+multibp (from /branches/innodb+:6914)
Creating a branch for the multiple buffer pool
------------------------------------------------------------------------
r6916 | sbains | 2010-03-31 08:21:00 +0300 (Wed, 31 Mar 2010) | 3 lines
Changed paths:
M /branches/innodb+multibp/CMakeLists.txt
M /branches/innodb+multibp/btr/btr0btr.c
M /branches/innodb+multibp/btr/btr0cur.c
M /branches/innodb+multibp/btr/btr0sea.c
M /branches/innodb+multibp/buf/buf0buddy.c
M /branches/innodb+multibp/buf/buf0buf.c
M /branches/innodb+multibp/buf/buf0flu.c
M /branches/innodb+multibp/buf/buf0lru.c
M /branches/innodb+multibp/buf/buf0rea.c
M /branches/innodb+multibp/handler/ha_innodb.cc
M /branches/innodb+multibp/handler/i_s.cc
M /branches/innodb+multibp/ibuf/ibuf0ibuf.c
M /branches/innodb+multibp/include/buf0buddy.h
M /branches/innodb+multibp/include/buf0buddy.ic
M /branches/innodb+multibp/include/buf0buf.h
M /branches/innodb+multibp/include/buf0buf.ic
M /branches/innodb+multibp/include/buf0flu.h
M /branches/innodb+multibp/include/buf0flu.ic
M /branches/innodb+multibp/include/buf0lru.h
M /branches/innodb+multibp/include/buf0rea.h
M /branches/innodb+multibp/include/buf0types.h
M /branches/innodb+multibp/include/ibuf0ibuf.ic
M /branches/innodb+multibp/include/srv0srv.h
M /branches/innodb+multibp/include/univ.i
M /branches/innodb+multibp/log/log0log.c
M /branches/innodb+multibp/log/log0recv.c
M /branches/innodb+multibp/mem/mem0mem.c
M /branches/innodb+multibp/page/page0zip.c
M /branches/innodb+multibp/srv/srv0srv.c
M /branches/innodb+multibp/srv/srv0start.c
M /branches/innodb+multibp/trx/trx0trx.c
M /branches/innodb+multibp/trx/trx0undo.c
branches/innodb+multibp: Unable to crash it with UNIV_DEBUG and UNIV_SYNC_DEBUG
with both ibtests and Sysbench. The patch now needs a workout from Michael.
------------------------------------------------------------------------
r6917 | sbains | 2010-03-31 08:56:18 +0300 (Wed, 31 Mar 2010) | 2 lines
Changed paths:
M /branches/innodb+multibp/handler/ha_innodb.cc
branches/innodb+multibp: Fix error introduced in r6916.
------------------------------------------------------------------------
r6923 | sbains | 2010-03-31 15:16:04 +0300 (Wed, 31 Mar 2010) | 3 lines
Changed paths:
M /branches/innodb+multibp/btr/btr0cur.c
M /branches/innodb+multibp/buf/buf0buddy.c
M /branches/innodb+multibp/buf/buf0buf.c
M /branches/innodb+multibp/buf/buf0flu.c
M /branches/innodb+multibp/buf/buf0lru.c
M /branches/innodb+multibp/include/buf0buddy.ic
M /branches/innodb+multibp/include/buf0buf.h
M /branches/innodb+multibp/include/buf0buf.ic
M /branches/innodb+multibp/include/buf0flu.ic
M /branches/innodb+multibp/page/page0zip.c
branches/innodb+multibp: Fix whitespace issues. Add function
buf_pool_from_block(). Add some comments to parameters.
------------------------------------------------------------------------
r6932 | sbains | 2010-04-01 01:12:07 +0300 (Thu, 01 Apr 2010) | 4 lines
Changed paths:
M /branches/innodb+multibp/include/buf0buf.ic
M /branches/innodb+multibp/include/univ.i
branches/innodb+multibp: Remove bogus assertion. It's possible for the space
and offset of a page to be undefined during the lifecycle of a page. Remove
the debug #defines from univ.i.
------------------------------------------------------------------------
r6933 | sbains | 2010-04-01 01:22:40 +0300 (Thu, 01 Apr 2010) | 2 lines
Changed paths:
M /branches/innodb+multibp/srv/srv0start.c
branches/innodb+multibp: Fix whitespace issues.
------------------------------------------------------------------------
r6934 | sbains | 2010-04-01 01:53:18 +0300 (Thu, 01 Apr 2010) | 2 lines
Changed paths:
M /branches/innodb+multibp/CMakeLists.txt
M /branches/innodb+multibp/ChangeLog
M /branches/innodb+multibp/buf/buf0buf.c
M /branches/innodb+multibp/buf/buf0flu.c
M /branches/innodb+multibp/handler/ha_innodb.cc
M /branches/innodb+multibp/include/buf0buf.h
M /branches/innodb+multibp/include/buf0buf.ic
M /branches/innodb+multibp/include/buf0flu.ic
M /branches/innodb+multibp/include/srv0srv.h
M /branches/innodb+multibp/include/sync0sync.h
M /branches/innodb+multibp/include/trx0purge.h
M /branches/innodb+multibp/include/ut0ut.h
M /branches/innodb+multibp/include/ut0ut.ic
M /branches/innodb+multibp/lock/lock0lock.c
M /branches/innodb+multibp/log/log0recv.c
M /branches/innodb+multibp/mtr/mtr0mtr.c
M /branches/innodb+multibp/mysql-test/innodb_bug38231.test
A /branches/innodb+multibp/mysql-test/innodb_bug51920.result (from /branches/innodb+/mysql-test/innodb_bug51920.result:6931)
A /branches/innodb+multibp/mysql-test/innodb_bug51920.test (from /branches/innodb+/mysql-test/innodb_bug51920.test:6931)
M /branches/innodb+multibp/row/row0sel.c
M /branches/innodb+multibp/srv/srv0srv.c
M /branches/innodb+multibp/srv/srv0start.c
M /branches/innodb+multibp/sync/sync0sync.c
M /branches/innodb+multibp/trx/trx0purge.c
branches/innodb+multibp: Merge revisions r6914:6931 from branches/innodb+
------------------------------------------------------------------------
r6935 | sbains | 2010-04-01 02:08:32 +0300 (Thu, 01 Apr 2010) | 3 lines
Changed paths:
M /branches/innodb+multibp/buf/buf0flu.c
M /branches/innodb+multibp/include/buf0flu.ic
M /branches/innodb+multibp/mtr/mtr0mtr.c
branches/innodb+multibp: Fix the debug assertions for flush order mutex. These
were missed in r6934.
------------------------------------------------------------------------
r6936 | sbains | 2010-04-01 02:46:52 +0300 (Thu, 01 Apr 2010) | 4 lines
Changed paths:
M /branches/innodb+multibp/sync/sync0sync.c
branches/innodb+multibp: Because now we have multiple instances of a mutex at
the same level and these mutexes can be acquired simultaneously we can't
simply check for <= level. We need to check for <= level - 1.
------------------------------------------------------------------------
r6937 | sbains | 2010-04-01 04:40:17 +0300 (Thu, 01 Apr 2010) | 5 lines
Changed paths:
M /branches/innodb+multibp/trx/trx0purge.c
branches/innodb+multibp: We need to check if the history list len is > than
some threshold not that it is evenly divisible by the some batch size. While
running tests on dscczz01 I've observed that the purge thread can't keep up
with the generation of the UNDO log records because of the faster code.
------------------------------------------------------------------------
r6938 | irana | 2010-04-01 10:15:00 +0300 (Thu, 01 Apr 2010) | 7 lines
Changed paths:
M /branches/innodb+multibp/buf/buf0buf.c
M /branches/innodb+multibp/buf/buf0flu.c
M /branches/innodb+multibp/include/buf0buf.h
M /branches/innodb+multibp/include/buf0buf.ic
M /branches/innodb+multibp/include/buf0flu.h
M /branches/innodb+multibp/include/buf0flu.ic
M /branches/innodb+multibp/include/log0log.h
M /branches/innodb+multibp/include/sync0sync.h
M /branches/innodb+multibp/log/log0log.c
M /branches/innodb+multibp/log/log0recv.c
M /branches/innodb+multibp/mtr/mtr0mtr.c
M /branches/innodb+multibp/sync/sync0sync.c
branches/innodb+multibp
The buf_flush_order patch that was ported in from 1.1 won't work with
multiple buffer pools. This patch moves the mutex protecting order of
insertion in the flush list(s) to log_sys struct so that we can have
one global mutex protecting insertions into all flush list(s)
------------------------------------------------------------------------
r6941 | sbains | 2010-04-02 00:51:28 +0300 (Fri, 02 Apr 2010) | 4 lines
Changed paths:
M /branches/innodb+multibp/lock/lock0lock.c
branches/innodb+multibp: We should get the record heap no to check recursively
only if we are checking a record lock. Prior to this fix we were doing it for
table locks as well, this is a bug.
------------------------------------------------------------------------
r6942 | csun | 2010-04-02 02:39:10 +0300 (Fri, 02 Apr 2010) | 4 lines
Changed paths:
M /branches/innodb+multibp/ha/ha0ha.c
branches/innodb+multibp: fix compiler errors on Windows.
Move ut_ad() to after declarations for C file.
------------------------------------------------------------------------
r6943 | sbains | 2010-04-03 05:14:25 +0300 (Sat, 03 Apr 2010) | 2 lines
Changed paths:
M /branches/innodb+multibp/buf/buf0buf.c
branches/innodb+multibp: Remove the code that created the fake buffer pool.
------------------------------------------------------------------------
r6945 | irana | 2010-04-05 23:35:29 +0300 (Mon, 05 Apr 2010) | 5 lines
Changed paths:
M /branches/innodb+multibp/lock/lock0lock.c
branches/innodb+multibp
Revert r6941 as it does not resolve the issue and we have to take
back the whole fix for bug#49047
------------------------------------------------------------------------
r6946 | irana | 2010-04-05 23:50:42 +0300 (Mon, 05 Apr 2010) | 6 lines
Changed paths:
M /branches/innodb+multibp/include/ut0ut.h
M /branches/innodb+multibp/include/ut0ut.ic
M /branches/innodb+multibp/lock/lock0lock.c
branches/innodb+multibp
Merged revisions 6932:6944 from branches/innodb+
This solely includes the reversal of fix for bug#49047
------------------------------------------------------------------------
r6947 | sbains | 2010-04-06 01:33:46 +0300 (Tue, 06 Apr 2010) | 3 lines
Changed paths:
M /branches/innodb+multibp/buf/buf0lru.c
branches/innodb+multibp: Remove the log sys mutex acquisition when doing
buffer pool stat aggregation. A dirty read here should suffice.
------------------------------------------------------------------------
r6951 | irana | 2010-04-06 17:25:29 +0300 (Tue, 06 Apr 2010) | 5 lines
Changed paths:
M /branches/innodb+multibp/buf/buf0buf.c
branches/innodb+mbp
Initialize the buf_page_t::buf_pool pointer when the descriptor is
allocated using buf_buddy_alloc().
------------------------------------------------------------------------
r6954 | jyang | 2010-04-06 21:24:46 +0300 (Tue, 06 Apr 2010) | 4 lines
Changed paths:
M /branches/innodb+multibp/handler/ha_innodb.cc
branches/innodb+multibp: Fix a possible null pointer of index_mapping
in a race condition.
------------------------------------------------------------------------
r6958 | sbains | 2010-04-07 00:27:44 +0300 (Wed, 07 Apr 2010) | 3 lines
Changed paths:
M /branches/innodb+multibp/include/ut0mem.h
M /branches/innodb+multibp/ut/ut0mem.c
branches/innodb+multibp: Fix part of Bug#52546. We allow ut_free() to accept
a NULL pointer and treat it as a nop.
------------------------------------------------------------------------
r6961 | jyang | 2010-04-07 10:50:03 +0300 (Wed, 07 Apr 2010) | 9 lines
Changed paths:
M /branches/innodb+multibp/handler/ha_innodb.cc
branches/innodb+multibp: Fix for bug #52580: Crash in
ha_innobase::open on executing INSERT with concurrent ALTER TABLE.
Change in MySQL bug #51557 releases the mutex LOCK_open before
ha_innobase::open(), causing racing condition for index translation
table creation. Fix it by adding dict_sys mutex for the operation.
rb://283, approved by Marko.
------------------------------------------------------------------------
r6963 | irana | 2010-04-07 19:14:10 +0300 (Wed, 07 Apr 2010) | 15 lines
Changed paths:
M /branches/innodb+multibp/handler/ha_innodb.cc
branches/innodb+multibp
Force setting of buf_pool->LRU_old_ratio by calling
buf_LRU_old_ratio_update() with adjust set to TRUE. This will make sure
that we grab the buf_pool mutex and actually adjust the
buf_pool->LRU_old pointer instead of just updating the
buf_pool->LRU_old_ratio.
Note that after this change there is no call to
buf_LRU_old_ratio_update() with adjust set to FALSE and therefore
this parameter should be removed. I am keeping it for now to first
make sure that the fix does work.
Approved by: No one. Sunny agreed with my hypothesis of the problem.
------------------------------------------------------------------------
r6964 | irana | 2010-04-07 19:59:59 +0300 (Wed, 07 Apr 2010) | 5 lines
Changed paths:
M /branches/innodb+multibp/handler/ha_innodb.cc
branches/innodb+multibp
Remove a too strong assertion on behalf of Jimmy.
------------------------------------------------------------------------
r6971 | sbains | 2010-04-09 13:23:33 +0300 (Fri, 09 Apr 2010) | 6 lines
Changed paths:
M /branches/innodb+multibp/buf/buf0buf.c
branches/innodb+multibp: When getting the oldest (minimum) LSN value from all
the flush lists we need to acquire the flush list mutex. We were incorrectly
acquiring the buffer pool mutex.
This patch should fix a slew of bugs reported by Michael.
------------------------------------------------------------------------
r6972 | sbains | 2010-04-10 00:25:09 +0300 (Sat, 10 Apr 2010) | 5 lines
Changed paths:
M /branches/innodb+multibp/buf/buf0buf.c
branches/innodb+multibp: We should not reset the lsn to 0 when we encounter
an empty flush list. Oldest LSN should be 0 only when all flush lists are empty.
e.g., without this fix if even one flush list was empty we would end up
breaking WAL.
------------------------------------------------------------------------
r6987 | sbains | 2010-04-14 00:14:13 +0300 (Wed, 14 Apr 2010) | 12 lines
Changed paths:
M /branches/innodb+multibp/buf/buf0buf.c
branches/innodb+multibp: When calculating the oldest_lsn we can have a
situation where we've iterated to say buffer pool 3 and another thread
adds two new dirty pages, the first to buffer pool 1 and the second to
buffer pool 4. Up to say buffer pool 3 the oldest_lsn was 0. Now, we will
end up returning the lsn at buffer pool 4 as the oldest LSN. We prevent this
by acquiring the flush order mutex.
One other future option is to calculate the min_lsn when flushing pages
from the list and maintaining a running total using atomics. That way
we can get rid of this function altogether. The atomics will only really
be required when we do parallel flushing.
------------------------------------------------------------------------
r6992 | sbains | 2010-04-14 02:45:59 +0300 (Wed, 14 Apr 2010) | 2 lines
Changed paths:
M /branches/innodb+multibp/include/ut0rbt.h
M /branches/innodb+multibp/ut/ut0rbt.c
branches/innodb+multibp: Fix copyright of the rbt code.
------------------------------------------------------------------------
This assertion could be triggered during execution of OPTIMIZE TABLE for
InnoDB tables. As part of optimize for InnoDB tables, the table is recreated
and then opened again. If the reopen failed for any reason, the assertion
would be triggered. This could for example be caused by a concurrent DROP
TABLE executed by a different connection. The reason for the assertion was
that any failures during reopening were ignored.
This patch fixes the problem by making sure that the result of reopening the
table is checked and that any error messages are sent to the client.
Test case added to innodb_mysql_sync.test.
This was a deadlock between CREATE/ALTER/DROP EVENT and a query
accessing both the mysql.event table and I_S.GLOBAL_VARIABLES.
The root of the problem was that the LOCK_event_metadata mutex was
used to both protect the "event_scheduler" global system variable
and the internal event data structures used by CREATE/ALTER/DROP EVENT.
The deadlock would occur if CREATE/ALTER/DROP EVENT held
LOCK_event_metadata while trying to open the mysql.event table,
at the same time as the query had mysql.event open, trying to
lock LOCK_event_metadata to access "event_scheduler".
This bug was fixed in the scope of Bug#51160 by using only
LOCK_global_system_variables to protect "event_scheduler".
This makes it so that the query above won't lock LOCK_event_metadata,
thereby preventing this deadlock from occuring.
This patch contains no code changes.
Test case added to lock_sync.test.
my_global.h first
We may end up with a compilation failure on certain platforms
because zlib.h is included before my_global.h.
Fixed by moving zlib.h inclusion down after my_global.h.
e.g.MYSQL_AUDIT_GENERAL_ERROR
General audit API (MYSQL_AUDIT_GENERAL_CLASS) didn't expose event
subclass to plugins.
This patch exposes event subclass to plugins via
struct mysql_event_general::event_subclass.
This change is not compatible with existing general audit plugins.
Audit interface major version has been incremented.
even if myisam-recover is OFF
The problem was that a corrupted MyISAM table was auto repaired
even if the myisam_recover_options server variable (or the
myisam_recover option) was set to OFF.
The reason was that the auto_repair() function, which is supposed
to say if auto repair is to be used, did not use the server variable
setting correctly. This bug was a regression introduced by WL#4738.
This patch fixes the problem by making sure auto_repair() returns
FALSE if myisam_recover_options is set to OFF.
Test case added to myisam.test.
------------------------------------------------------------
revno: 2875.107.114
revision-id: dlenev@mysql.com-20100201114306-cve0yq5akrxjoei0
parent: dlenev@mysql.com-20100121204303-sr6d1436mac7x6vz
committer: Dmitry Lenev <dlenev@mysql.com>
branch nick: mysql-next-4284-nl-push
timestamp: Mon 2010-02-01 14:43:06 +0300
message:
Implement new type-of-operation-aware metadata locks.
Add a wait-for graph based deadlock detector to the
MDL subsystem.
Fixes bug #46272 "MySQL 5.4.4, new MDL: unnecessary deadlock" and
bug #37346 "innodb does not detect deadlock between update and
alter table".
The first bug manifested itself as an unwarranted abort of a
transaction with ER_LOCK_DEADLOCK error by a concurrent ALTER
statement, when this transaction tried to repeat use of a
table, which it has already used in a similar fashion before
ALTER started.
The second bug showed up as a deadlock between table-level
locks and InnoDB row locks, which was "detected" only after
innodb_lock_wait_timeout timeout.
A transaction would start using the table and modify a few
rows.
Then ALTER TABLE would come in, and start copying rows
into a temporary table. Eventually it would stumble on
the modified records and get blocked on a row lock.
The first transaction would try to do more updates, and get
blocked on thr_lock.c lock.
This situation of circular wait would only get resolved
by a timeout.
Both these bugs stemmed from inadequate solutions to the
problem of deadlocks occurring between different
locking subsystems.
In the first case we tried to avoid deadlocks between metadata
locking and table-level locking subsystems, when upgrading shared
metadata lock to exclusive one.
Transactions holding the shared lock on the table and waiting for
some table-level lock used to be aborted too aggressively.
We also allowed ALTER TABLE to start in presence of transactions
that modify the subject table. ALTER TABLE acquires
TL_WRITE_ALLOW_READ lock at start, and that block all writes
against the table (naturally, we don't want any writes to be lost
when switching the old and the new table). TL_WRITE_ALLOW_READ
lock, in turn, would block the started transaction on thr_lock.c
lock, should they do more updates. This, again, lead to the need
to abort such transactions.
The second bug occurred simply because we didn't have any
mechanism to detect deadlocks between the table-level locks
in thr_lock.c and row-level locks in InnoDB, other than
innodb_lock_wait_timeout.
This patch solves both these problems by moving lock conflicts
which are causing these deadlocks into the metadata locking
subsystem, thus making it possible to avoid or detect such
deadlocks inside MDL.
To do this we introduce new type-of-operation-aware metadata
locks, which allow MDL subsystem to know not only the fact that
transaction has used or is going to use some object but also what
kind of operation it has carried out or going to carry out on the
object.
This, along with the addition of a special kind of upgradable
metadata lock, allows ALTER TABLE to wait until all
transactions which has updated the table to go away.
This solves the second issue.
Another special type of upgradable metadata lock is acquired
by LOCK TABLE WRITE. This second lock type allows to solve the
first issue, since abortion of table-level locks in event of
DDL under LOCK TABLES becomes also unnecessary.
Below follows the list of incompatible changes introduced by
this patch:
- From now on, ALTER TABLE and CREATE/DROP TRIGGER SQL (i.e. those
statements that acquire TL_WRITE_ALLOW_READ lock)
wait for all transactions which has *updated* the table to
complete.
- From now on, LOCK TABLES ... WRITE, REPAIR/OPTIMIZE TABLE
(i.e. all statements which acquire TL_WRITE table-level lock) wait
for all transaction which *updated or read* from the table
to complete.
As a consequence, innodb_table_locks=0 option no longer applies
to LOCK TABLES ... WRITE.
- DROP DATABASE, DROP TABLE, RENAME TABLE no longer abort
statements or transactions which use tables being dropped or
renamed, and instead wait for these transactions to complete.
- Since LOCK TABLES WRITE now takes a special metadata lock,
not compatible with with reads or writes against the subject table
and transaction-wide, thr_lock.c deadlock avoidance algorithm
that used to ensure absence of deadlocks between LOCK TABLES
WRITE and other statements is no longer sufficient, even for
MyISAM. The wait-for graph based deadlock detector of MDL
subsystem may sometimes be necessary and is involved. This may
lead to ER_LOCK_DEADLOCK error produced for multi-statement
transactions even if these only use MyISAM:
session 1: session 2:
begin;
update t1 ... lock table t2 write, t1 write;
-- gets a lock on t2, blocks on t1
update t2 ...
(ER_LOCK_DEADLOCK)
- Finally, support of LOW_PRIORITY option for LOCK TABLES ... WRITE
was abandoned.
LOCK TABLE ... LOW_PRIORITY WRITE from now on has the same
priority as the usual LOCK TABLE ... WRITE.
SELECT HIGH PRIORITY no longer trumps LOCK TABLE ... WRITE in
the wait queue.
- We do not take upgradable metadata locks on implicitly
locked tables. So if one has, say, a view v1 that uses
table t1, and issues:
LOCK TABLE v1 WRITE;
FLUSH TABLE t1; -- (or just 'FLUSH TABLES'),
an error is produced.
In order to be able to perform DDL on a table under LOCK TABLES,
the table must be locked explicitly in the LOCK TABLES list.
@ mysql-test/include/handler.inc
Adjusted test case to trigger an execution path on which bug 41110
"crash with handler command when used concurrently with alter
table" and bug 41112 "crash in mysql_ha_close_table/get_lock_data
with alter table" were originally discovered. Left old test case
which no longer triggers this execution path for the sake of
coverage.
Added test coverage for HANDLER SQL statements and type-aware
metadata locks.
Added a test for the global shared lock and HANDLER SQL.
Updated tests to take into account that the old simple deadlock
detection heuristics was replaced with a graph-based deadlock
detector.
@ mysql-test/r/debug_sync.result
Updated results (see debug_sync.test).
@ mysql-test/r/handler_innodb.result
Updated results (see handler.inc test).
@ mysql-test/r/handler_myisam.result
Updated results (see handler.inc test).
@ mysql-test/r/innodb-lock.result
Updated results (see innodb-lock.test).
@ mysql-test/r/innodb_mysql_lock.result
Updated results (see innodb_mysql_lock.test).
@ mysql-test/r/lock.result
Updated results (see lock.test).
@ mysql-test/r/lock_multi.result
Updated results (see lock_multi.test).
@ mysql-test/r/lock_sync.result
Updated results (see lock_sync.test).
@ mysql-test/r/mdl_sync.result
Updated results (see mdl_sync.test).
@ mysql-test/r/sp-threads.result
SHOW PROCESSLIST output has changed due to the fact that waiting
for LOCK TABLES WRITE now happens within metadata locking
subsystem.
@ mysql-test/r/truncate_coverage.result
Updated results (see truncate_coverage.test).
@ mysql-test/suite/funcs_1/datadict/processlist_val.inc
SELECT FROM I_S.PROCESSLIST output has changed due to fact that
waiting for LOCK TABLES WRITE now happens within metadata locking
subsystem.
@ mysql-test/suite/funcs_1/r/processlist_val_no_prot.result
SELECT FROM I_S.PROCESSLIST output has changed due to fact that
waiting for LOCK TABLES WRITE now happens within metadata locking
subsystem.
@ mysql-test/suite/rpl/t/rpl_sp.test
Updated to a new SHOW PROCESSLIST state name.
@ mysql-test/t/debug_sync.test
Use LOCK TABLES READ instead of LOCK TABLES WRITE as the latter
no longer allows to trigger execution path involving waiting on
thr_lock.c lock and therefore reaching debug sync-point covered
by this test.
@ mysql-test/t/innodb-lock.test
Adjusted test case to the fact that innodb_table_locks=0 option is
no longer supported, since LOCK TABLES WRITE handles all its
conflicts within MDL subsystem.
@ mysql-test/t/innodb_mysql_lock.test
Added test for bug #37346 "innodb does not detect deadlock between
update and alter table".
@ mysql-test/t/lock.test
Added test coverage which checks the fact that we no longer support
DDL under LOCK TABLES on tables which were locked implicitly.
Adjusted existing test cases accordingly.
@ mysql-test/t/lock_multi.test
Added test for bug #46272 "MySQL 5.4.4, new MDL: unnecessary
deadlock". Adjusted other test cases to take into account the
fact that waiting for LOCK TABLES ... WRITE now happens within MDL
subsystem.
@ mysql-test/t/lock_sync.test
Since LOCK TABLES ... WRITE now takes SNRW metadata lock for
tables locked explicitly we have to implicitly lock InnoDB tables
(through view) to trigger the table-level lock conflict between
TL_WRITE and TL_WRITE_ALLOW_WRITE.
@ mysql-test/t/mdl_sync.test
Added basic test coverage for type-of-operation-aware metadata
locks. Also covered with tests some use cases involving HANDLER
statements in which a deadlock could arise.
Adjusted existing tests to take type-of-operation-aware MDL into
account.
@ mysql-test/t/multi_update.test
Update to a new SHOW PROCESSLIST state name.
@ mysql-test/t/truncate_coverage.test
Adjusted test case after making LOCK TABLES WRITE to wait until
transactions that use the table to be locked are completed.
Updated to the changed name of DEBUG_SYNC point.
@ sql/handler.cc
Global read lock functionality has been
moved into a class.
@ sql/lock.cc
Global read lock functionality has been
moved into a class.
Updated code to use the new MDL API.
@ sql/mdl.cc
Introduced new type-of-operation aware metadata locks.
To do this:
- Changed MDL_lock to use one list for waiting requests and one
list for granted requests. For each list, added a bitmap
that holds information what lock types a list contains.
Added a helper class MDL_lock::List to manipulate with granted
and waited lists while keeping the bitmaps in sync
with list contents.
- Changed lock-compatibility functions to use bitmaps that
define compatibility.
- Introduced a graph based deadlock detector inspired by
waiting_threads.c from Maria implementation.
- Now that we have a deadlock detector, and no longer have
a global lock to protect individual lock objects, but rather
use an rw lock per object, removed redundant code for upgrade,
and the global read lock. Changed the MDL API to
no longer require the caller to acquire the global
intention exclusive lock by means of a separate method.
Removed a few more methods that became redundant.
- Removed deadlock detection heuristic, it has been made
obsolete by the deadlock detector.
- With operation-type-aware metadata locks, MDL subsystem has
become aware of potential conflicts between DDL and open
transactions. This made it possible to remove calls to
mysql_abort_transactions_with_shared_lock() from acquisition
paths for exclusive lock and lock upgrade. Now we can simply
wait for these transactions to complete without fear of
deadlock. Function mysql_lock_abort() has also become
unnecessary for all conflicting cases except when a DDL
conflicts with a connection that has an open HANDLER.
@ sql/mdl.h
Introduced new type-of-operation aware metadata locks.
Introduced a graph based deadlock detector and supporting
methods.
Added comments.
God rid of redundant API calls.
Renamed m_lt_or_ha_sentinel to m_trans_sentinel,
since now it guards the global read lock as well as
LOCK TABLES and HANDLER locks.
@ sql/mysql_priv.h
Moved the global read lock functionality into a
class.
Added MYSQL_OPEN_FORCE_SHARED_MDL flag which forces
open_tables() to take MDL_SHARED on tables instead of
metadata locks specified in the parser. We use this to
allow PREPARE run concurrently in presence of
LOCK TABLES ... WRITE.
Added signature for find_table_for_mdl_ugprade().
@ sql/set_var.cc
Global read lock functionality has been
moved into a class.
@ sql/sp_head.cc
When creating TABLE_LIST elements for prelocking or
system tables set the type of request for metadata
lock according to the operation that will be performed
on the table.
@ sql/sql_base.cc
- Updated code to use the new MDL API.
- In order to avoid locks starvation we take upgradable
locks all at once. As result implicitly locked tables no
longer get an upgradable lock. Consequently DDL and FLUSH
TABLES for such tables is prohibited.
find_write_locked_table() was replaced by
find_table_for_mdl_upgrade() function.
open_table() was adjusted to return TABLE instance with
upgradable ticket when necessary.
- We no longer wait for all locks on OT_WAIT back off
action -- only on the lock that caused the wait
conflict. Moreover, now we distinguish cases when we
have to wait due to conflict in MDL and old version
of table in TDC.
- Upate mysql_notify_threads_having_share_locks()
to only abort thr_lock.c waits of threads that
have open HANDLERs, since lock conflicts with only
these threads now can lead to deadlocks not detectable
by the MDL deadlock detector.
- Remove mysql_abort_transactions_with_shared_locks()
which is no longer needed.
@ sql/sql_class.cc
Global read lock functionality has been moved into a class.
Re-arranged code in THD::cleanup() to simplify assert.
@ sql/sql_class.h
Introduced class to incapsulate global read lock
functionality.
Now sentinel in MDL subsystem guards the global read lock
as well as LOCK TABLES and HANDLER locks. Adjusted code
accordingly.
@ sql/sql_db.cc
Global read lock functionality has been moved into a class.
@ sql/sql_delete.cc
We no longer acquire upgradable metadata locks on tables
which are locked by LOCK TABLES implicitly. As result
TRUNCATE TABLE is no longer allowed for such tables.
Updated code to use the new MDL API.
@ sql/sql_handler.cc
Inform MDL_context about presence of open HANDLERs.
Since HANLDERs break MDL protocol by acquiring table-level
lock while holding only S metadata lock on a table MDL
subsystem should take special care about such contexts (Now
this is the only case when mysql_lock_abort() is used).
@ sql/sql_parse.cc
Global read lock functionality has been moved into a class.
Do not take upgradable metadata locks when opening tables
for CREATE TABLE SELECT as it is not necessary and limits
concurrency.
When initializing TABLE_LIST objects before adding them
to the table list set the type of request for metadata lock
according to the operation that will be performed on the
table.
We no longer acquire upgradable metadata locks on tables
which are locked by LOCK TABLES implicitly. As result FLUSH
TABLES is no longer allowed for such tables.
@ sql/sql_prepare.cc
Use MYSQL_OPEN_FORCE_SHARED_MDL flag when opening
tables during PREPARE. This allows PREPARE to run
concurrently in presence of LOCK TABLES ... WRITE.
@ sql/sql_rename.cc
Global read lock functionality has been moved into a class.
@ sql/sql_show.cc
Updated code to use the new MDL API.
@ sql/sql_table.cc
Global read lock functionality has been moved into a class.
We no longer acquire upgradable metadata locks on tables
which are locked by LOCK TABLES implicitly. As result DROP
TABLE is no longer allowed for such tables.
Updated code to use the new MDL API.
@ sql/sql_trigger.cc
Global read lock functionality has been moved into a class.
We no longer acquire upgradable metadata locks on tables
which are locked by LOCK TABLES implicitly. As result
CREATE/DROP TRIGGER is no longer allowed for such tables.
Updated code to use the new MDL API.
@ sql/sql_view.cc
Global read lock functionality has been moved into a class.
Fixed results of wrong merge that led to misuse of GLR API.
CREATE VIEW statement is not a commit statement.
@ sql/table.cc
When resetting TABLE_LIST objects for PS or SP re-execution
set the type of request for metadata lock according to the
operation that will be performed on the table. Do the same
in auxiliary function initializing metadata lock requests
in a table list.
@ sql/table.h
When initializing TABLE_LIST objects set the type of request
for metadata lock according to the operation that will be
performed on the table.
@ sql/transaction.cc
Global read lock functionality has been moved into a class.
The problem was that the code that works with stored routines was present
in mysql_system_tables.sql. This is wrong because until upgrade is finished,
stored routines may be (and were) not available.
The fix is to move that code to the end of mysql_system_tables_fix.sql.
