![](https://secure.gravatar.com/avatar/99fde0c1dfd216326aae0aff30d493f1.jpg?s=120&d=mm&r=g)
Hi Serg, Here is the status of my efforts to merge the rpl,binlog, and innodb suites. These are the tests that still fail after my last pust to 5.5-serg: binlog.binlog_innodb_row This fails because of a problem in my merge of group commit, I will fix. binlog.binlog_killed I do not know yet, I can take a look next week. binlog.binlog_index This fails because of missing --test-expect-abort option which you said you would re-add back. rpl.rpl_create_if_not_exists Something with CREATE IF NOT EXISTS, I believe you said you would look at this (not related to replication). rpl.rpl_variables_stm This looks like microsecond related, maybe you can check. innodb.innodb innodb.innodb_no_mrricp innodb.innodb_mysql I think we should ask someone from optimiser to take a look at these. - Kristian.
![](https://secure.gravatar.com/avatar/3c2329333dd5898f2e72818af773243d.jpg?s=120&d=mm&r=g)
Hi, Kristian! About LOCK_log, LOCK_index, LOCK_thread_count and the Bug#62614: 1. In mysql-5.5.13, that we're merging with, LOCK_thread_count is called *after* LOCK_log and LOCK_index. Perhaps it was your merge of log.cc where you swapped them. 2. But in the latest 5.5 as on launchpad, LOCK_thread_count comes before LOCK_log and LOCK_index - they've changed it recently. 3. LOCK_thd_data should go after LOCK_thread_count, because LOCK_thread_count is taken around 'delete thd', and LOCK_thd_data - in the THD destructor. 4. LOCK_log should go after LOCK_thd_data, because LOCK_thd_data is taken around THD::awake(), and THD::awake() locks, mysys_var->current_mutex, which is LOCK_log in MYSQL_BIN_LOG::wait_for_update_relay_log() 5. from 3 and 4 follows that LOCK_thread_count should be locked before LOCK_log, not after. Incidentally, when I did that, almost all safemutex deadlock detector warnings dissapeared (those that I've seen in every rpl test; there are be few in individual tests still). Regards, Sergei
![](https://secure.gravatar.com/avatar/6856a1f0f722fbef5eef6f496fc6fab3.jpg?s=120&d=mm&r=g)
A maybe provocatice question: Did you consider to discard MySQL 5.5 and
focus on 5.6 instead for the next major MariaDB relelase?
-- PETER
On Fri, Oct 7, 2011 at 22:45, Sergei Golubchik
Hi, Kristian!
About LOCK_log, LOCK_index, LOCK_thread_count and the Bug#62614:
1. In mysql-5.5.13, that we're merging with, LOCK_thread_count is called *after* LOCK_log and LOCK_index. Perhaps it was your merge of log.cc where you swapped them.
2. But in the latest 5.5 as on launchpad, LOCK_thread_count comes before LOCK_log and LOCK_index - they've changed it recently.
3. LOCK_thd_data should go after LOCK_thread_count, because LOCK_thread_count is taken around 'delete thd', and LOCK_thd_data - in the THD destructor.
4. LOCK_log should go after LOCK_thd_data, because LOCK_thd_data is taken around THD::awake(), and THD::awake() locks, mysys_var->current_mutex, which is LOCK_log in MYSQL_BIN_LOG::wait_for_update_relay_log()
5. from 3 and 4 follows that LOCK_thread_count should be locked before LOCK_log, not after. Incidentally, when I did that, almost all safemutex deadlock detector warnings dissapeared (those that I've seen in every rpl test; there are be few in individual tests still).
Regards, Sergei
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
![](https://secure.gravatar.com/avatar/3c2329333dd5898f2e72818af773243d.jpg?s=120&d=mm&r=g)
Hi, Peter! On Oct 07, Peter Laursen wrote:
A maybe provocatice question: Did you consider to discard MySQL 5.5 and focus on 5.6 instead for the next major MariaDB relelase?
We didn't, as far as I know (which means, this idea is neither rejected nor accepted :). But it doesn't change anything for what I'm doing short term - we still need to complete the 5.5 merge, and then merge 5.6 into it. Regards, Sergei
participants (3)
-
Kristian Nielsen
-
Peter Laursen
-
Sergei Golubchik