maria-developers team mailing list archive
Mailing list archive
Re: 334e7c9: MDEV-7895 - HANDLER READ doesn't upgrade metadata lock from S to SR
On May 07, Sergey Vojtovich wrote:
> revision-id: 334e7c9bccbc6892efbb35f5930f80ccf1d770a8
> parent(s): cbc5157feb9801310e458f7ed10983ad478c881e
> committer: Sergey Vojtovich
> branch nick: mariadb
> timestamp: 2015-04-01 14:07:02 +0400
> MDEV-7895 - HANDLER READ doesn't upgrade metadata lock from S to SR
> Change code for HANDLER READ statements to upgrade S metadata lock to
> SR metadata lock for the duration of read. This allows us properly
> isolate HANDLER READ from LOCK TABLES WRITE and makes metadata locking
> for these statements consistent with locking for other DML.
> HANDLER-related tests had to be adjusted to take into account that
> HANDLER READ will wait for and acquire SR lock.
code-wise it's ok, but I'm not sure I like the resulting behavior. Here,
the very first test:
con1: handler t1 open;
con2: drop table t1; -- waits
con1: handler t1 read; -- deadlock
as a user I'd expect that after handler open, I can use the handler. I
don't care about locks, but supposedly handler open should take them all
or handler read should solve it somehow, why I, a user, should bother?
So, indeed, one option would be to acquire SR lock on handler open.
Also, note the comment for MDL_SHARED:
A shared metadata lock.
To be used in cases when we are interested in object metadata only
and there is no intention to access object data (e.g. for stored
routines or during preparing prepared statements).
We also mis-use this type of lock for open HANDLERs, since lock
acquired by this statement has to be compatible with lock acquired
by LOCK TABLES ... WRITE statement, i.e. SNRW (We can't get by by
acquiring S lock at HANDLER ... OPEN time and upgrading it to SR
lock for HANDLER ... READ as it doesn't solve problem with need
to abort DML statements which wait on table level lock while having
open HANDLER in the same connection).
To avoid deadlock which may occur when SNRW lock is being upgraded to
X lock for table on which there is an active S lock which is owned by
thread which waits in its turn for table-level lock owned by thread
performing upgrade we have to use thr_abort_locks_for_thread()
facility in such situation.
This problem does not arise for locks on stored routines as we don't
use SNRW locks for them. It also does not arise when S locks are used
during PREPARE calls as table-level locks are not acquired in this
Which begs more questions:
- why open handler lock has to be compatible with SNRW?
- why using S and upgrading to SR "didn't solve the problem" and now it