Hi!
>>>>> "Guilhem" == Guilhem Bichot <guilhem@stripped> writes:
Guilhem> Hello,
Guilhem> Michael Widenius a écrit :
>> #At bzr+ssh://bk-internal.mysql.com/bzrroot/server/mysql-maria/
>>
>> 2699 Michael Widenius 2008-11-05
>> Fix for bug: Bug #40391 Maria deadlock in trnman_get_min_trid , trnman_end_trn
Guilhem> Thanks for the fix!
Guilhem> I took a quick look at one stack trace of the bug report and couldn't
Guilhem> understand what the problem was. Could you please describe what scenario
Guilhem> caused the deadlock: what the two threads were doing (functions,
Guilhem> mutexes) which caused them to wait for each other?
The deadlock happens becasue of different mutex locking order.
thread 1)
- end_of_transaction -> _ma_trnman_end_trans_hook.
This aquires mutex in the order:
LOCK_trn_list -> share->intern_lock
thread 2)
On close table, we call _ma_remove_not_visible_states() which will
call trnman_get_min_trid() under a share lock.
This takes mutex in the following order:
share->intern_lock -> LOCK_trn_list
For the close, the above *should* be safe as the share should not be
used by anyone, but somehow we got a hang here.
I took the easy way out and removed the case altogether.
Guilhem> Isn't there any problem with the read-without-mutex below, if the
Guilhem> architecture is 32-bit where 64-bit reads are not atomic (one can in
Guilhem> theory get a mix of old 4 bytes and new 4 bytes) ? If that happens,
Guilhem> won't there be a chance of removing transaction ids which shouldn't be
Guilhem> removed?
Yes, there is a potential problem, but I don't think it's relevant for
Maria; All 32 bit systems that has been produced the last 5 years are
should be safe for 64 bit reads (even unaligned).
We could add another mutex just for this case for old 32 bit systems,
but I don't think it's relevant just now.
Regards,
Monty
