| Bug #39320 | assert btr/btr0pcur.c line 217 -innodb_locks_unsafe_for_binlog or read committed | ||
|---|---|---|---|
| Submitted: | 8 Sep 2008 15:53 | Modified: | 18 Jun 2010 22:35 |
| Reporter: | Shane Bester (Platinum Quality Contributor) | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: InnoDB storage engine | Severity: | S1 (Critical) |
| Version: | 5.1.15->5.1.32, 6.0.9, 6.0.12 | OS: | Any |
| Assigned to: | Satya B | CPU Architecture: | Any |
| Tags: | innodb_locks_unsafe_for_binlog, regression | ||
[8 Sep 2008 15:53]
Shane Bester
[8 Sep 2008 15:59]
MySQL Verification Team
btr/btr0pcur.c line 217 looks like this:
index = btr_cur_get_index(btr_pcur_get_btr_cur(cursor));
if (UNIV_UNLIKELY(cursor->old_stored != BTR_PCUR_OLD_STORED)
|| UNIV_UNLIKELY(cursor->pos_state != BTR_PCUR_WAS_POSITIONED
&& cursor->pos_state != BTR_PCUR_IS_POSITIONED)) {
ut_print_buf(stderr, cursor, sizeof(btr_pcur_t));
if (cursor->trx_if_known) {
trx_print(stderr, cursor->trx_if_known, 0);
}
ut_error;
}
[8 Sep 2008 19:19]
MySQL Verification Team
I analyzed the hex output of cursor values leading to the assertion, here's the values for each field: cursor->btr_cur.index = b8c45bb8aa2a0000 cursor->btr_cur.page_cur = ac4922c7aa2a0000 cursor->btr_cur.left_page = 0000000000000000 cursor->btr_cur.thr = 0000000000000000 cursor->btr_cur.flag = 0300000000000000 (BTR_CUR_BINARY) cursor->btr_cur.tree_height= 0300000000000000 cursor->btr_cur.up_match = 0000000000000000 cursor->btr_cur.up_bytes = 0300000000000000 cursor->btr_cur.low_match = 0100000000000000 cursor->btr_cur.low_bytes = 0000000000000000 cursor->btr_cur.n_fields = 0000000000000000 cursor->btr_cur.n_bytes = 0000000000000000 cursor->btr_cur.fold = 0000000000000000 cursor->btr_cur.path_arr = 0000000000000000 cursor->latch_mode = 0100000000000000 cursor->old_stored = 8344510700000000 cursor->old_rec = 0000000000000000 cursor->old_n_field = 0000000000000000 cursor->rel_pos = 0000000000000000 cursor->block_when_stored = 0000000000000000 cursor->modify_clock = 00000000000000000000000000000000 cursor->pos_state = 60e1117700000000 cursor->search_mode = 0400000000000000 cursor->trx_if_known* = b87027b9aa2a0000 cursor->mtr* = 0000000000000000 cursor->old_rec_buf* = 0000000000000000 cursor->buf_size = 0000000000000000 as we see, cursor->pos_state is BTR_PCUR_IS_POSITIONED. cursor->old_stored is BTR_PCUR_OLD_NOT_STORED. This is a problem I think.
[9 Sep 2008 4:37]
Valeriy Kravchuk
Looks similar to bug #15650. I am not sure that patch for that bug is included into 5.1...
[27 Jan 2009 17:45]
Andrii Nikitin
I've checked fix for bug #15650, it is in 5.1 also
[25 Feb 2009 22:50]
MySQL Verification Team
TESTCASE: --------- drop table if exists `t1`,`t2`; create table `t1` (`a` int, `b` int) engine=innodb; create table `t2` (`c` int, `d` int, key `c` (`c`)) engine=innodb; insert into `t1` values (1,1); insert into `t2` values (1,2); delete from `t1` using `t1` join `t2` on `t1`.`a` = `t2`.`c` where `t2`.`d` in (1);
[26 Feb 2009 7:01]
Valeriy Kravchuk
5.0.74 works as expected, so this is a regression that may prevent successful upgrade to 5.1.
[26 Feb 2009 8:36]
Marko Mäkelä
I can reproduce it with innodb_locks_unsafe_for_binlog=1 but not with set transaction isolation level read committed; even though the two should be equivalent. This is related to semi-consistent reads. Unlocking the clustered index record of t2 will fail, probably because the clustered index of t2 wasn't needed in the lookup in the first place. I don't know if a semi-consistent read should be attempted for t2 at all, since that table is only read by the DELETE statement. See Bug #43160.
[26 Feb 2009 23:28]
Laine Campbell
This still has not been fixed in 5.1.31. centos: 2.6.18-53.el5 #1 SMP Mon Nov 12 02:14:55 EST 2007 x86_64 x86_64 x86_64 GNU/Linux Server version: 5.1.26-rc-log MySQL Community Server (GPL) (also tested in .31 with identical results) Error log: hex b8c015dbaa2a00009aa705deaa2a00000000000000000000000000000000000002000000000000000300000000000000000000000000000007000000000000000100000000000000000000000000000001000000000000000000000000000000fe688022852cd2ad00000000000000000100000000000000834451070000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000060e11177000000000400000000000000b88015dbaa2a0000000000000000000000000000000000000000000000000000; asc * * h " , DQ ` w * ;TRANSACTION 0 1498368, ACTIVE 0 sec, process no 31351, OS thread id 1159788864 unlock_row, thread declared inside InnoDB 255 mysql tables in use 3, locked 3 1651 lock struct(s), heap size 161776, 99265 row lock(s) MySQL thread id 7, query id 41 localhost root Sending data DELETE ft FROM agg_c_group_keyword_instance_fact_21_60 ft, ( SELECT sub.a FROM ( SELECT DISTINCT(publisher_group_id) as a FROM agg_c_group_keyword_instance_fact_21_60 ) sub LEFT JOIN keyword_instance_dim_21_60 dimTable ON sub.a = dimTable.publisher_group_id WHERE ( dimTable.client_account_id in (163) ) ) b WHERE ft.publisher_group_id = b.a 090226 22:16:55 InnoDB: Assertion failure in thread 1159788864 in file btr/btr0pcur.c line 217 InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html InnoDB: about forcing recovery. /usr/local/mysql/bin/mysqld(my_print_stacktrace+0x2e)[0x89b4be] /usr/local/mysql/bin/mysqld(handle_segfault+0x322)[0x5d29f2] /lib64/libpthread.so.0[0x31f800de70] /lib64/libc.so.6(gsignal+0x35)[0x31f7430055] /lib64/libc.so.6(abort+0x110)[0x31f7431af0] /usr/local/mysql/bin/mysqld(btr_pcur_restore_position+0x93)[0x829d83] /usr/local/mysql/bin/mysqld(row_unlock_for_mysql+0x21b)[0x7e8b1b] /usr/local/mysql/bin/mysqld[0x62cca4] /usr/local/mysql/bin/mysqld(_Z10sub_selectP4JOINP13st_join_tableb+0x78)[0x632078] /usr/local/mysql/bin/mysqld[0x62cc25] /usr/local/mysql/bin/mysqld(_Z10sub_selectP4JOINP13st_join_tableb+0x96)[0x632096] /usr/local/mysql/bin/mysqld[0x6349f5] /usr/local/mysql/bin/mysqld(_ZN4JOIN4execEv+0x936)[0x64af76] /usr/local/mysql/bin/mysqld(_Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x124)[0x646ff4] /usr/local/mysql/bin/mysqld(_Z21mysql_derived_fillingP3THDP6st_lexP10TABLE_LIST+0x117)[0x712137] /usr/local/mysql/bin/mysqld(_Z20mysql_handle_derivedP6st_lexPFbP3THDS0_P10TABLE_LISTE+0x6a)[0x711faa] /usr/local/mysql/bin/mysqld(_Z28open_and_lock_tables_derivedP3THDP10TABLE_LISTb+0x156)[0x61db46] /usr/local/mysql/bin/mysqld(_Z21mysql_execute_commandP3THD+0x4ae8)[0x5e7518] /usr/local/mysql/bin/mysqld(_Z11mysql_parseP3THDPKcjPS2_+0x357)[0x5e8297] /usr/local/mysql/bin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0xe63)[0x5e9103] /usr/local/mysql/bin/mysqld(_Z10do_commandP3THD+0xe6)[0x5e99c6] /usr/local/mysql/bin/mysqld(handle_one_connection+0x236)[0x5dc636] /lib64/libpthread.so.0[0x31f80062f7] /lib64/libc.so.6(clone+0x6d)[0x31f74ce85d] 090226 22:16:55 - mysqld got signal 6 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=536870912 read_buffer_size=8388608 max_used_connections=5 max_threads=1000 threads_connected=5 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 16918452 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd: 0x6a99740 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... stack_bottom = 0x4520f100 thread_stack 0x40000 Trying to get some variables. Some pointers may be invalid and cause the dump to abort... thd->query at 0x6aa47b0 = DELETE ft FROM agg_c_group_keyword_instance_fact_21_60 ft, ( SELECT sub.a FROM ( SELECT DISTINCT(publisher_group_id) as a FROM agg_c_group_keyword_instance_fact_21_60 ) sub LEFT JOIN keyword_instance_dim_21_60 dimTable ON sub.a = dimTable.publisher_group_id WHERE ( dimTable.client_account_id in (163) ) ) b WHERE ft.publisher_group_id = b.a thd->thread_id=7 thd->killed=NOT_KILLED my.cnf [client] port = 3306 socket = /tmp/mysql.sock [mysqld] server-id = 1004 port = 3306 socket = /tmp/mysql.sock basedir = /usr/local/mysql datadir = /usr/local/mysql/data init_connect = 'SET NAMES utf8' max_connections = 1000 max_connect_errors = 10 max_allowed_packet = 8M skip-locking log-bin = /var/log/mysql/mysql-bin binlog_cache_size = 1M max_binlog_size = 1G expire_logs_days = 10 binlog-ignore-db = test log-queries-not-using-indexes log-slow-queries = /var/log/mysql/xxxxx-slow-query.log log-error = /var/log/mysql/xxxxx-error.log long_query_time = 10 log-warnings = 2 sync_binlog = 1 table_cache = 4096 thread_cache_size = 8 query_cache_size = 256M query_cache_limit = 4M local_infile = 1 key_buffer_size = 512M myisam_sort_buffer_size = 64M myisam_recover innodb_data_home_dir = /usr/local/mysql/data/ innodb_data_file_path = ibdata1:10M:autoextend innodb_log_group_home_dir = /usr/local/mysql/data/ innodb_buffer_pool_size = 1G innodb_additional_mem_pool_size = 8M innodb_flush_log_at_trx_commit = 1 innodb_lock_wait_timeout = 400 innodb_file_per_table innodb_locks_unsafe_for_binlog = 0 innodb_thread_concurrency = 20 sort_buffer_size = 8M read_buffer_size = 8M read_rnd_buffer_size = 8M join_buffer_size = 16M log-slave-updates relay-log = /var/log/mysql/xxxxxxxx-relay relay-log-info-file = /var/log/mysql/xxxxxxxx-relay-log.info relay-log-index = /var/log/mysql/xxxxxxxx-relay-log.index slave_transaction_retries = 60 [mysqldump] quick max_allowed_packet = 16M [mysql] no-auto-rehash [isamchk] key_buffer = 128M sort_buffer_size = 128M read_buffer = 32M write_buffer = 32M [myisamchk] key_buffer = 128M sort_buffer_size = 128M read_buffer = 32M write_buffer = 32M [mysqlhotcopy] interactive-timeout
[27 Feb 2009 12:40]
Marko Mäkelä
Nobody claimed that the bug had been fixed. I said that I can't reproduce with the READ COMMITTED isolation level, but that was because I did not realize that the isolation level is reset in autocommit mode. An explicit BEGIN helps: drop table if exists t1,t2; create table t1 (a int, b int) engine=innodb; create table t2 (c int, d int, key (c)) engine=innodb; begin; set session transaction isolation level read committed; insert into t1 values (1,1); insert into t2 values (1,2); delete from t1 using t1 join t2 on t1.a = t2.c where t2.d in (1); commit; The DELETE statement will crash. The crash will occur even if t1 is defined as a MyISAM table.
[6 Mar 2009 14:25]
Marko Mäkelä
Fix: row_sel_get_clust_rec_for_mysql() should store the cursor position for unlock_row().
[12 Mar 2009 14:21]
River Tarnell
Where can I find the patch?
[16 Mar 2009 14:17]
Jason Galloway
Could someone let me know where to find the patch?
[19 Mar 2009 15:49]
Calvin Sun
Patch for bug#39320
Attachment: r4399.patch (text/x-patch), 1.77 KiB.
[15 Apr 2009 11:46]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/72144 2858 Satya B 2009-04-15 Applying InnoDB snashot 5.1-ss4699, part 1. Fixes BUG#39320 and other problems 1) BUG#39320 - innodb crash in file btr/btr0pcur.c line 217 with innodb_locks_unsafe_for_binlog 2) Fixes bug in multi-table semi consistent reads. 3) Fixes email address from dev@innodb.com to innodb_dev_ww@oracle.com 4) Fixes warning message generated by main.innodb test Detailed revision comments: r4399 | marko | 2009-03-12 09:38:05 +0200 (Thu, 12 Mar 2009) | 5 lines branches/5.1: row_sel_get_clust_rec_for_mysql(): Store the cursor position also for unlock_row(). (Bug #39320) rb://96 approved by Heikki Tuuri. r4400 | marko | 2009-03-12 10:06:44 +0200 (Thu, 12 Mar 2009) | 8 lines branches/5.1: Fix a bug in multi-table semi-consistent reads. Remember the acquired record locks per table handle (row_prebuilt_t) rather than per transaction (trx_t), so that unlock_row should successfully unlock all non-matching rows in multi-table operations. This deficiency was found while investigating Bug #39320. rb://94 approved by Heikki Tuuri. r4481 | marko | 2009-03-19 15:01:48 +0200 (Thu, 19 Mar 2009) | 6 lines branches/5.1: row_unlock_for_mysql(): Do not unlock records that were modified by the current transaction. This bug was introduced or unmasked in r4400. rb://97 approved by Heikki Tuuri r4573 | vasil | 2009-03-30 14:17:13 +0300 (Mon, 30 Mar 2009) | 4 lines branches/5.1: Fix email address from dev@innodb.com to innodb_dev_ww@oracle.com r4574 | vasil | 2009-03-30 14:27:08 +0300 (Mon, 30 Mar 2009) | 38 lines branches/5.1: Restore the state of INNODB_THREAD_CONCURRENCY to silence this warning: TEST RESULT TIME (ms) ------------------------------------------------------------ worker[1] Using MTR_BUILD_THREAD 250, with reserved ports 12500..12509 main.innodb [ pass ] 8803 MTR's internal check of the test case 'main.innodb' failed. This means that the test case does not preserve the state that existed before the test case was executed. Most likely the test case did not do a proper clean-up. This is the diff of the states of the servers before and after the test case was executed: mysqltest: Logging to '/tmp/autotest.sh-20090330_033000-5.1.5Hg8CY/mysql-5.1/mysql-test/var/tmp/check-mysqld_1.log'. mysqltest: Results saved in '/tmp/autotest.sh-20090330_033000-5.1.5Hg8CY/mysql-5.1/mysql-test/var/tmp/check-mysqld_1.result'. mysqltest: Connecting to server localhost:12500 (socket /tmp/autotest.sh-20090330_033000-5.1.5Hg8CY/mysql-5.1/mysql-test/var/tmp/mysqld.1.sock) as 'root', connection 'default', attempt 0 ... mysqltest: ... Connected. mysqltest: Start processing test commands from './include/check-testcase.test' ... mysqltest: ... Done processing test commands. --- /tmp/autotest.sh-20090330_033000-5.1.5Hg8CY/mysql-5.1/mysql-test/var/tmp/check-mysqld_1.result 2009-03-30 14:12:31.000000000 +0300 +++ /tmp/autotest.sh-20090330_033000-5.1.5Hg8CY/mysql-5.1/mysql-test/var/tmp/check-mysqld_1.reject 2009-03-30 14:12:41.000000000 +0300 @@ -99,7 +99,7 @@ INNODB_SUPPORT_XA ON INNODB_SYNC_SPIN_LOOPS 20 INNODB_TABLE_LOCKS ON -INNODB_THREAD_CONCURRENCY 8 +INNODB_THREAD_CONCURRENCY 16 INNODB_THREAD_SLEEP_DELAY 10000 INSERT_ID 0 INTERACTIVE_TIMEOUT 28800 mysqltest: Result content mismatch not ok r4576 | vasil | 2009-03-30 16:25:10 +0300 (Mon, 30 Mar 2009) | 4 lines branches/5.1: Revert a change to Makefile.am that I committed accidentally in c4574. modified: mysql-test/r/innodb-semi-consistent.result mysql-test/t/innodb-semi-consistent.test mysql-test/t/innodb.test storage/innobase/include/row0mysql.h storage/innobase/include/trx0trx.h storage/innobase/include/trx0trx.ic storage/innobase/lock/lock0lock.c storage/innobase/row/row0mysql.c storage/innobase/row/row0sel.c storage/innobase/trx/trx0trx.c
[20 Apr 2009 6:59]
Satya B
Notes to Docs team: Patch queued to 5.1-bugteam. NOT yet in 6.0 (5.1-snapshot-ss4699 is null merged into 6.0). Please return to "Patch approved" after documenting until 6.0 snapshot is available.
[27 Apr 2009 20:51]
Daniel Bakken
This bug is also present in MySQL 5.4-beta:
OS: Solaris 10
len 224; hex f8d8bba203000000ecac9fb900000000010000000000000000069ba20300000003000000000000000300000000000000020000000000000003000000000000000300000000000000000000000000000004000000000000000100000000000000050000800000000008000000000000000100000000000000834451070000000000000000000000000000000000000000000000000000000000000000000000000000000000100000f0e60a010000000060e11177000000000400000000000000785799a2030000000000000000000000000000000000000099e3e380da8c67bc; asc DQ ` w xW g ;TRANSACTION 0 681031276, ACTIVE 7 sec, OS thread id 40 unlock_row, thread declared inside InnoDB 475
mysql tables in use 3, locked 3
1097 lock struct(s), heap size 145392, 175932 row lock(s)
MySQL thread id 728, query id 247110 fafnir.ccb 192.168.5.22 mackerman Copying to tmp table
REPLACE INTO reis_final.reis_final_beta12407199685
select b.CountyID, b.IndID, b.Year, b.Emp,
IF(b.Earn/b.Emp < x.blimit, (x.blimit * b.Emp),
IF(b.Earn/b.Emp > x.ulimit, (x.ulimit * b.Emp),
b.Earn)) as Earn
from reis_final.reis_final_beta12407199685 b
INNER JOIN ind_definition.naics_2002_to_reis_6digit map ON b.IndID = map.IndID
INNER JOIN
(
select lineid, max(earn/emp) as ulimit, min(earn/emp) as blimit
from reis_final.reis_final_alpha where emp > 10 and year = 2006
GROUP BY LineID, Year
) AS x ON x.LineID = map.reis
WHERE b.Year = 2006 AND b.Emp != 0
090425 23:28:06 InnoDB: Assertion failure in thread 40 in file btr/btr0pcur.c line 217
[5 May 2009 19:38]
Bugs System
Pushed into 5.1.35 (revid:davi.arnaut@sun.com-20090505190206-9xmh7dlc6kom8exp) (version source revid:davi.arnaut@sun.com-20090505190206-9xmh7dlc6kom8exp) (merge vers: 5.1.35) (pib:6)
[6 May 2009 14:11]
Bugs System
Pushed into 6.0.12-alpha (revid:svoj@sun.com-20090506125450-yokcmvqf2g7jhujq) (version source revid:satya.bn@sun.com-20090415130616-z1o0xrb1lv340ser) (merge vers: 6.0.11-alpha) (pib:6)
[13 May 2009 23:24]
Paul DuBois
Noted in 5.1.35, 6.0.12 changelogs. In an UPDATE or DELETE via a secondary index, InnoDB did not store the cursor position. This made InnoDB crash in semi-consistent read while attempting to unlock a non-matching record.
[19 May 2009 20:03]
MySQL Verification Team
See bug: http://bugs.mysql.com/bug.php?id=44959.
[19 May 2009 20:08]
MySQL Verification Team
Bug: http://bugs.mysql.com/bug.php?id=44959 was marked as duplicate of this one.
[21 May 2009 13:10]
MySQL Verification Team
bug #45007 is a duplicate of this
[15 Jun 2009 8:25]
Bugs System
Pushed into 5.1.35-ndb-6.3.26 (revid:jonas@mysql.com-20090615074202-0r5r2jmi83tww6sf) (version source revid:jonas@mysql.com-20090615070837-9pccutgc7repvb4d) (merge vers: 5.1.35-ndb-6.3.26) (pib:6)
[15 Jun 2009 9:05]
Bugs System
Pushed into 5.1.35-ndb-7.0.7 (revid:jonas@mysql.com-20090615074335-9hcltksp5cu5fucn) (version source revid:jonas@mysql.com-20090615072714-rmfkvrbbipd9r32c) (merge vers: 5.1.35-ndb-7.0.7) (pib:6)
[15 Jun 2009 9:45]
Bugs System
Pushed into 5.1.35-ndb-6.2.19 (revid:jonas@mysql.com-20090615061520-sq7ds4yw299ggugm) (version source revid:jonas@mysql.com-20090615054654-ebgpz7elwu1xj36j) (merge vers: 5.1.35-ndb-6.2.19) (pib:6)
[8 Jul 2009 13:30]
Bugs System
Pushed into 5.1.37 (revid:joro@sun.com-20090708131116-kyz8iotbum8w9yic) (version source revid:joro@sun.com-20090622115751-e2946ixgjf73narz) (merge vers: 5.1.37) (pib:11)
[9 Jul 2009 7:36]
Bugs System
Pushed into 5.1.37 (revid:joro@sun.com-20090708131116-kyz8iotbum8w9yic) (version source revid:joro@sun.com-20090622115751-e2946ixgjf73narz) (merge vers: 5.1.37) (pib:11)
[10 Jul 2009 11:21]
Bugs System
Pushed into 5.4.4-alpha (revid:anozdrin@bk-internal.mysql.com-20090710111017-bnh2cau84ug1hvei) (version source revid:satya.bn@sun.com-20090622113236-j8cc6krsju4qe1iq) (merge vers: 5.4.4-alpha) (pib:11)
[10 Jul 2009 23:19]
Bugs System
Pushed into 5.1.37 (revid:build@mysql.com-20090710231213-9guqdu0avc0uwdkp) (version source revid:build@mysql.com-20090710231213-9guqdu0avc0uwdkp) (merge vers: 5.1.37) (pib:11)
[23 Jul 2009 10:24]
Bugs System
Pushed into 5.4.4-alpha (revid:alik@sun.com-20090723102221-ps4uaphwbxzj8p0q) (version source revid:joerg@mysql.com-20090721145751-rqqnhv0kage18wfi) (merge vers: 5.4.4-alpha) (pib:11)
[3 Aug 2009 12:29]
MySQL Verification Team
Bug http://bugs.mysql.com/bug.php?id=45302 marked as duplicate of this one.
[11 Aug 2009 11:21]
MySQL Verification Team
See bug: http://bugs.mysql.com/bug.php?id=46647.
[26 Aug 2009 13:46]
Bugs System
Pushed into 5.1.37-ndb-7.0.8 (revid:jonas@mysql.com-20090826132541-yablppc59e3yb54l) (version source revid:jonas@mysql.com-20090826132541-yablppc59e3yb54l) (merge vers: 5.1.37-ndb-7.0.8) (pib:11)
[26 Aug 2009 13:46]
Bugs System
Pushed into 5.1.37-ndb-6.3.27 (revid:jonas@mysql.com-20090826105955-bkj027t47gfbamnc) (version source revid:jonas@mysql.com-20090826105955-bkj027t47gfbamnc) (merge vers: 5.1.37-ndb-6.3.27) (pib:11)
[26 Aug 2009 13:48]
Bugs System
Pushed into 5.1.37-ndb-6.2.19 (revid:jonas@mysql.com-20090825194404-37rtosk049t9koc4) (version source revid:jonas@mysql.com-20090825194404-37rtosk049t9koc4) (merge vers: 5.1.37-ndb-6.2.19) (pib:11)
[27 Aug 2009 16:33]
Bugs System
Pushed into 5.1.35-ndb-7.1.0 (revid:magnus.blaudd@sun.com-20090827163030-6o3kk6r2oua159hr) (version source revid:jonas@mysql.com-20090826132541-yablppc59e3yb54l) (merge vers: 5.1.37-ndb-7.0.8) (pib:11)
[5 May 2010 15:22]
Bugs System
Pushed into 5.1.47 (revid:joro@sun.com-20100505145753-ivlt4hclbrjy8eye) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
[6 May 2010 7:29]
Roel Van de Paar
"Pushed into 5.1.37" > Closed > "Pushed into 5.1.47" > Documenting Could someone clarify what is happening here? Is the patch in 5.1.37?
[6 May 2010 16:02]
Paul DuBois
Push resulted from incorporation of InnoDB tree. No changes pertinent to this bug. Re-closing.
[28 May 2010 6:13]
Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100524190136-egaq7e8zgkwb9aqi) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (pib:16)
[28 May 2010 6:41]
Bugs System
Pushed into 6.0.14-alpha (revid:alik@sun.com-20100524190941-nuudpx60if25wsvx) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
[28 May 2010 7:09]
Bugs System
Pushed into 5.5.5-m3 (revid:alik@sun.com-20100524185725-c8k5q7v60i5nix3t) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
[29 May 2010 2:52]
Paul DuBois
Push resulted from incorporation of InnoDB tree. No changes pertinent to this bug. Re-closing.
[15 Jun 2010 8:18]
Bugs System
Pushed into 5.5.5-m3 (revid:alik@sun.com-20100615080459-smuswd9ooeywcxuc) (version source revid:mmakela@bk-internal.mysql.com-20100415070122-1nxji8ym4mao13ao) (merge vers: 5.1.47) (pib:16)
[15 Jun 2010 8:35]
Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100615080558-cw01bzdqr1bdmmec) (version source revid:mmakela@bk-internal.mysql.com-20100415070122-1nxji8ym4mao13ao) (pib:16)
[17 Jun 2010 12:20]
Bugs System
Pushed into 5.1.47-ndb-7.0.16 (revid:martin.skold@mysql.com-20100617114014-bva0dy24yyd67697) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
[17 Jun 2010 13:07]
Bugs System
Pushed into 5.1.47-ndb-6.2.19 (revid:martin.skold@mysql.com-20100617115448-idrbic6gbki37h1c) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
[17 Jun 2010 13:48]
Bugs System
Pushed into 5.1.47-ndb-6.3.35 (revid:martin.skold@mysql.com-20100617114611-61aqbb52j752y116) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
[4 Dec 2010 12:44]
huang shuhuai
“Push resulted from incorporation of InnoDB tree. No changes pertinent to this bug. Re-closing.” what are these means? is the bug fixed or not? i encouter this bug too.
[5 Dec 2010 8:48]
James Day
There's sometimes a lot of "noise" in the commit messages due to the number of source code trees and versions we maintain, with a message being generated each time something is added to each version. Here's the important bit: ---------- [14 May 2009 1:24] Paul DuBois Noted in 5.1.35, 6.0.12 changelogs. In an UPDATE or DELETE via a secondary index, InnoDB did not store the cursor position. This made InnoDB crash in semi-consistent read while attempting to unlock a non-matching record. ---------- It'll also be in 5.5 even though that isn't mentioned because of the age of the message.
