| Bug #45961 | DDL on partitioned innodb tables leaves data dictionary in an inconsistent state | ||
|---|---|---|---|
| Submitted: | 6 Jul 2009 7:26 | Modified: | 7 Jan 2010 13:25 |
| Reporter: | Shane Bester (Platinum Quality Contributor) | Email Updates: | |
| Status: | Duplicate | Impact on me: | |
| Category: | MySQL Server: InnoDB storage engine | Severity: | S1 (Critical) |
| Version: | 5.1.34, 5.1.37, 6.0.12 | OS: | Any |
| Assigned to: | Assigned Account | CPU Architecture: | Any |
[6 Jul 2009 7:26]
Shane Bester
[6 Jul 2009 7:42]
MySQL Verification Team
if you shutdown the server and restart it and rerun the testcase, innodb dies due to memory corruption!
Attachment: bug_after_restart_crash_memory_corruption.txt (text/plain), 8.18 KiB.
[6 Jul 2009 9:32]
Sveta Smirnova
Thank you for the report. Verified as described.
[6 Jul 2009 13:31]
MySQL Verification Team
note to developers: it's possible you'll also hit bug #45808 with this testcase..
[10 Jul 2009 14:01]
Andrii Nikitin
Verified if the original procedure split into two: first does DDL, second - DML. If started with no configuration file mysqld crashes after 1 min of running the test. G:\mysql-5.1.36-winbuild\mysql-advanced-gpl-5.1.36-build\storage\innobase\include\sync0syn c.ic line 115 000000014033D320 mysqld.exe!row_get_mysql_key_number_for_index()[row0mysql.c:1677] 0000000140334DFB mysqld.exe!ha_innobase::info()[ha_innodb.cc:6224] 0000000140042917 mysqld.exe!ha_partition::info()[ha_partition.cc:4935] 000000014004ACD7 mysqld.exe!handler::get_dup_key()[handler.cc:2954] 000000014004E05F mysqld.exe!handler::print_error()[handler.cc:2612] 00000001401AD637 mysqld.exe!mysql_change_partitions()[sql_partition.cc:5102] 00000001401B45E7 mysqld.exe!fast_alter_partition_table()[sql_partition.cc:6354] 000000014020B93B mysqld.exe!mysql_alter_table()[sql_table.cc:6905] 00000001401A4AC4 mysqld.exe!mysql_execute_command()[sql_parse.cc:2861] 000000014013FBE8 mysqld.exe!sp_instr_stmt::exec_core()[sp_head.cc:2908] 0000000140143395 mysqld.exe!sp_lex_keeper::reset_lex_and_exec_core()[sp_head.cc:2735] 0000000140143596 mysqld.exe!sp_instr_stmt::execute()[sp_head.cc:2851] 0000000140144FC5 mysqld.exe!sp_head::execute()[sp_head.cc:1255] 000000014014638F mysqld.exe!sp_head::execute_procedure()[sp_head.cc:1983] 00000001401A7144 mysqld.exe!mysql_execute_command()[sql_parse.cc:4359] If started with --innodb_flush_log_at_trx_commit=0 --innodb_doublewrite=0 --innodb_lock_wait_timeout=1 --innodb_file_per_table then no crash, just following errors appear in log 090710 15:42:26 InnoDB: Error creating file '.\part\t1#p#p0#tmp#.ibd'.
[10 Jul 2009 14:50]
MySQL Verification Team
andrii, your last stack trace is reported in bug #45808 . it's garbage pointer deref. if you use debug build, it'll make an assertion instead of psuedorandom crash.
[20 Jul 2009 13:25]
Andrii Nikitin
1) looks the problem occurs when "Lock wait timeout exceeded" risen by ALTER statement. 2) server restart removes temporary files 3) if ALTER TABLE ADD PARTITION executed again immediately after restart then crash with stacktrace identical to bug #45808 . 4) if SELECT * executed first after server restart, then 3) will not crash 5) I tried to manually delete the problem #TMP# files and finished with full table data loss (except last partition) 6) increasing innodb_lock_wait_timeout will not help in most cases because of bug #37346 e.g. if in original testcase we will wrap 'replace' statement with 'start transaction' and 'commit;', then problem will occur only with very small innodb_lock_wait_timeout value.
[6 Aug 2009 12:16]
Marko Mäkelä
When investigating Bug #45808, I saw similar error messages when running with innodb_file_per_table=1. The messages went away with innodb_file_per_table=0.
[10 Aug 2009 13:03]
Marko Mäkelä
While trying to repeat this, I got one case of apparent duplicate call of row_prebuilt_free(): InnoDB: Error: trying to free a corrupt InnoDB: table handle. Magic n 26423527, magic n2 26423527, table name "test"."#mysql50#t1#P#p0#TMP#" InnoDB: Apparent memory corruption: mem dump len 500; … This is with my fix for Bug #45808 from [6 Aug 12:39] in place. It looks like the partition code is calling ha_innobase::close() on an already closed handle. I was unable to repeat that crash. I got a similar crash from the Bug #45808 test case before applying my fix. Also, like with Bug #45808, innodb_file_per_table=1 makes InnoDB spam the log with this kind of messages: 090810 15:51:47 InnoDB: Error creating file './test/t1#P#p0#TMP#.ibd'. 090810 15:51:47 InnoDB: Operating system error number 17 in a file operation. InnoDB: Error number 17 means 'File exists'. With innodb_file_per_table=0, it only spams this: 090810 16:00:47 InnoDB: Error: table `test`.`#mysql50#t1#P#p0#TMP#` already exists in InnoDB internal InnoDB: data dictionary. … Both are signs of inconsistent data dictionaries. I will investigate this further.
[10 Aug 2009 13:06]
Marko Mäkelä
Regarding [6 Jul 9:42], I got the “double ha_innobase::close()” error after killing and restarting the server and the test case. Like in the attached file, I had “Magic n 26423527, magic n2 26423527” in the error message. This is ROW_PREBUILT_FREED, suggesting that row_prebuilt_free() had already been called on the object. row_prebuilt_free() was called by ha_innobase::close(), which in turn was called by ha_partition::close().
[8 Sep 2009 17:50]
Jimmy Yang
Part of the root cause for this crash will be addressed in bug #47029. We will address the error code returning part in this CR, per suggestion from Mikael. Some email exchange explains the discussion on this issue. Please also refer to bug 47029 for more infomartion. Thanks Jimmy ======================Email Exchange with Mikael ========================== Hi, Jimmy Yang wrote: > Mikael, briefly chatted with Heikki on this, we will change the error return code (in this particular situation) from DB_DUPLICATE_KEY to generic DB_ERROR (though feel a big uneasy not returning an real error code to go around the error reporting issue :) ). > > I'll use #45961 to make the change, and will update the bug description with these information. > > For DROP TABLE related issues, I'll need to do some background checks... > Great, thx. I have already pushed your suggested change to the bug tree so should soon appear in the 5.1 tree. Rgrds Mikael Hi, If you want to hang your error handling bug to another bug you can use BUG#45961 which is crashing due to the same problem and stack trace is very similar. I have also noted that there is a few bugs related to the problem that InnoDB does a certain amount of DROP TABLE processing in the background after the SQL query DROP TABLE already have been processed. It seems that Partitioning management escalates this problem since it is very common practice to reuse partition names it seems. See BUG#45961, BUG#43729. I don't know if you already have a plan for fixing this issue. I gather you have. Rgrds Mikael Jimmy Yang wrote: > Thanks, Mikael. > >> I gather a good work division is that I handle >> the below patch and that you handle the error handling. > > Yes, Mikael, for error handling, I will do some > digging and see how we go from there. > > > > Thanks > Jimmy ========================================================
[9 Sep 2009 3:25]
Jimmy Yang
Here are some more debugging information on the problem:
The prebuilt structure is the one that got freed and thus triggerred the SIGSEGV when mysql_rename_partitions() failed with dup key error and get_dup_key() got called etc.
Program received signal SIGSEGV, Segmentation fault.
0x00000000008a1949 in row_update_prebuilt_trx (prebuilt=0x2aaaaad96cb8,
trx=0x2aaaaad8e0b8) at row/row0mysql.c:787
787 ut_print_name(stderr, NULL, TRUE, prebuilt->table->name);
(gdb) print prebuilt->table->name
Cannot access memory at address 0x1a
However, the prebuilt structure is freed just a couple of lines before mysql_rename_partitions() is called in fast_alter_partition_table(), following is the call stack:
row_prebuilt_free
ha_innobase::close
ha_partition::close
close_handle_and_leave_table_as_lock
close_data_files_and_morph_locks
alter_close_tables <== Table closed right before rename tbl.
fast_alter_partition_table ( sql_partition.cc:6380)
mysql_alter_table
mysql_rename_partitions() is called right after alter_close_tables() in the same if () statement at sql_partition.cc:6380. If alter these two sequence, this SIGSEGV due to freed "prebuilt" could go away, but it will still fail because some of the transaction information for this operation has gone away.
My general suggestion for this is that we should try to avoid re-entering /re-access innodb code from mysql layer for error printing. It will be good all the innodb error being handled locally right when error happens, and information are available. And use error push, to push the error message up.
What I am going to do for this bug is still following what Mikael/Heikki suggested and change the return code from DB_DUPLICATE_KEY to DB_ERROR for table rename. But use push_warning_printf() to push some error information up.
Thanks
Jimmy
[3 Nov 2009 11:04]
Mattias Jonsson
Changing to Category: InnoDB. Jimmy, if you need some change in the partitioning area, please contact me or open a new bug. As I understand this bug, it is about error handling in InnoDB (as noted in bug#45808).
[20 Nov 2009 2:47]
Jimmy Yang
Please note, the problem for the bug could well be fixed in bug #47029. The current fix is just to avoid the SIGSEGV in the error handling situation.
[20 Nov 2009 5:58]
Jimmy Yang
Fix checked in. Again, this is to prevent a future server crash if a similar error (a failure to drop temp table causing a dup key error) happens. Please refer to bug #47029 for real fix of the problem.
[30 Nov 2009 9:04]
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/92031 3216 Satya B 2009-11-30 Applying InnoDB snapshot 5.1-ss6242, part 5. Fixes BUG#45961 1. BUG#45961 - DDL on partitioned innodb tables leaves data dictionary in an inconsistent state 2. Fix formatting Detailed revision comments: r6205 | jyang | 2009-11-20 07:55:48 +0200 (Fri, 20 Nov 2009) | 11 lines branches/5.1: Add a special case to handle the Duplicated Key error and return DB_ERROR instead. This is to avoid a possible SIGSEGV by mysql error handling re-entering the storage layer for dup key info without proper table handle. This is to prevent a server crash when error situation in bug #45961 "DDL on partitioned innodb tables leaves data dictionary in an inconsistent state" happens. rb://157 approved by Sunny Bains. r6206 | jyang | 2009-11-20 09:38:43 +0200 (Fri, 20 Nov 2009) | 3 lines branches/5.1: Non-functional change, fix formatting.
[1 Dec 2009 9:16]
Satya B
patch queued to 5.1-bugteam storage/innobase and for the plugin storage/innodb_ plugin. NULL merged to 6.0 and will be merged to 5.5.*
[2 Dec 2009 8:06]
Bugs System
Pushed into 5.1.42 (revid:joro@sun.com-20091202080033-mndu4sxwx19lz2zs) (version source revid:satya.bn@sun.com-20091130090357-otu81dm00kgbe2hp) (merge vers: 5.1.42) (pib:13)
[14 Dec 2009 22:45]
Harrison Fisk
I was testing the fix for this bug, and am still getting similar errors: 091214 17:27:33 InnoDB: Error creating file './test/t1#P#p0#TMP#.ibd'. 091214 17:27:33 InnoDB: Operating system error number 17 in a file operation. InnoDB: Error number 17 means 'File exists'. InnoDB: Some operating system error numbers are described at InnoDB: http://dev.mysql.com/doc/refman/5.1/en/operating-system-error-codes.html InnoDB: The file already exists though the corresponding table did not InnoDB: exist in the InnoDB data dictionary. Have you moved InnoDB InnoDB: .ibd files around without using the SQL commands InnoDB: DISCARD TABLESPACE and IMPORT TABLESPACE, or did InnoDB: mysqld crash in the middle of CREATE TABLE? You can InnoDB: resolve the problem by removing the file './test/t1#P#p0#TMP#.ibd' InnoDB: under the 'datadir' of MySQL. This was built from the bzr tree and I confirmed the fix was indeed present: shell$ bzr log| grep -B 5 -A 5 45961 ... revno: 3216 committer: Satya B <satya.bn@sun.com> branch nick: mysql-5.1-bugteam timestamp: Mon 2009-11-30 14:33:57 +0530 message: Applying InnoDB snapshot 5.1-ss6242, part 5. Fixes BUG#45961 1. BUG#45961 - DDL on partitioned innodb tables leaves data dictionary in an inconsistent state ...
[16 Dec 2009 8:39]
Bugs System
Pushed into 6.0.14-alpha (revid:alik@sun.com-20091216083311-xorsasf5kopjxshf) (version source revid:alik@sun.com-20091214191830-wznm8245ku8xo702) (merge vers: 6.0.14-alpha) (pib:14)
[16 Dec 2009 8:46]
Bugs System
Pushed into 5.5.0-beta (revid:alik@sun.com-20091216082430-s0gtzibcgkv4pqul) (version source revid:satya.bn@sun.com-20091202114649-zt975apdali0jy3c) (merge vers: 5.5.0-beta) (pib:14)
[16 Dec 2009 8:52]
Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20091216083231-rp8ecpnvkkbhtb27) (version source revid:alik@sun.com-20091212203859-fx4rx5uab47wwuzd) (merge vers: 5.6.0-beta) (pib:14)
[18 Dec 2009 23:22]
Mattias Jonsson
test case from bug#45808 fails too. (That bug was marked as a duplicate of this and should fixed in the scope of this bug too, if not shown to be a non related crash.)
[19 Dec 2009 1:28]
Mattias Jonsson
Seems to be bad error recovery in the partitioning code, it does not remove the temporary partition when copy_partitions fails. I will reopen bug#45808 since that test still fails and try to handle it there, leaving this bug as 'innodb returns dup_key error when existing table is found'.
[6 Jan 2010 14:42]
Jimmy Yang
Originally this bug is a placeholder to fix the return dup error causing mysql server crash as discussed with Mikael for bug #47029. A second look into the bug found there is also a bug almost identical to #47343 need to fixed. The bug is to address temp table not cleaned up when an HA_ERR_LOCK_WAIT_TIMEOUT is hit (notice this bug happens quickly when you shorten the timeout setting). For a detail look at the cause, please also reference description in bug #47343. Following are debug information showing evidence of similar cause as bug #47343: In following stack, you will see we hit DB_LOCK_WAIT_TIMEOUT and later HA_ERR_LOCK_WAIT_TIMEOUT error (gdb) n 463 ut_a(err != DB_SUCCESS); (gdb) p err $2 = 35 Error 35 is DB_LOCK_WAIT_TIMEOUT and later HA_ERR_LOCK_WAIT_TIMEOUT error for mysql. (#define DB_LOCK_WAIT_TIMEOUT 35 /* lock wait lasted too long */) ================================= (gdb) where #0 row_mysql_handle_errors (new_err=0x45b420f8, trx=0x2aaaaad8e0b8, thr=0x2aaaaad95350, savept=0x0) at row/row0mysql.c:463 #1 0x00000000008ae2ad in row_search_for_mysql ( buf=0x1a9084b8 "ÿ", ' ' <repeats 199 times>..., mode=1, prebuilt=0x2aaaaada10b8, match_mode=0, direction=0) at row/row0sel.c:4359 #2 0x0000000000841539 in ha_innobase::index_read (this=0x1a9076c8, buf=0x1a9084b8 "ÿ", ' ' <repeats 199 times>..., key_ptr=0x0, key_len=0, find_flag=HA_READ_AFTER_KEY) at handler/ha_innodb.cc:4663 #3 0x0000000000840913 in ha_innobase::index_first (this=0x1a9076c8, buf=0x1a9084b8 "ÿ", ' ' <repeats 199 times>...) at handler/ha_innodb.cc:4927 #4 0x0000000000840d03 in ha_innobase::rnd_next (this=0x1a9076c8, buf=0x1a9084b8 "ÿ", ' ' <repeats 199 times>...) at handler/ha_innodb.cc:5024 #5 0x000000000076a7dd in ha_partition::copy_partitions (this=0x1a8d8298, copied=0x45b42d60, deleted=0x45b42d68) at ha_partition.cc:1642 #6 0x000000000076b5f2 in ha_partition::change_partitions (this=0x1a8d8298, create_info=0x45b44310, path=0x45b42790 "./test/t1", copied=0x45b42d60, deleted=0x45b42d68, pack_frm_data=0x0, pack_frm_len=0) at ha_partition.cc:1594 #7 0x0000000000759618 in handler::ha_change_partitions (this=0x1a8d8298, create_info=0x45b44310, path=0x45b42790 "./test/t1", copied=0x45b42d60, deleted=0x45b42d68, pack_frm_data=0x0, pack_frm_len=0) at handler.cc:3405 ---Type <return> to continue, or q <return> to quit--- #8 0x000000000052b996 in mysql_change_partitions (lpt=0x45b42a30) at sql_partition.cc:5109 #9 0x000000000052c9f6 in fast_alter_partition_table (thd=0x1a8a1da8, table=0x1a8d79b8, alter_info=0x45b44c10, create_info=0x45b44310, table_list=0x1a8ca660, db=0x1a8b9088 "test", table_name=0x1a8ca628 "t1", fast_alter_partition=1) at sql_partition.cc:6343 #10 0x000000000077f7fb in mysql_alter_table (thd=0x1a8a1da8, new_db=0x1a8b9088 "test", new_name=0x1a8ca628 "t1", create_info=0x45b44310, table_list=0x1a8ca660, alter_info=0x45b44c10, order_num=0, order=0x0, ignore=false) at sql_table.cc:6939 #11 0x0000000000626e3a in mysql_execute_command (thd=0x1a8a1da8) at sql_parse.cc:2858 #12 0x00000000007edd5b in sp_instr_stmt::exec_core (this=0x1a8cca60, thd=0x1a8a1da8, nextp=0x45b45288) at sp_head.cc:2905 #13 0x00000000007ee72e in sp_lex_keeper::reset_lex_and_exec_core ( this=0x1a8ccaa0, thd=0x1a8a1da8, nextp=0x45b45288, open_tables=false, instr=0x1a8cca60) at sp_head.cc:2734 #14 0x00000000007eee12 in sp_instr_stmt::execute (this=0x1a8cca60, thd=0x1a8a1da8, nextp=0x45b45288) at sp_head.cc:2848 #15 0x00000000007f110d in sp_head::execute (this=0x1a8b8be8, thd=0x1a8a1da8) at sp_head.cc:1252 #16 0x00000000007f1e97 in sp_head::execute_procedure (this=0x1a8b8be8, thd=0x1a8a1da8, args=0x1a8a4118) at sp_head.cc:1982 ---Type <return> to continue, or q <return> to quit--- ================================= Breakpoint 2, ha_partition::copy_partitions (this=0x96a1be8, copied=0x4619dd60, deleted=0x4619dd68) at ha_partition.cc:1644 1644 if (result == HA_ERR_RECORD_DELETED) (gdb) 1646 if (result != HA_ERR_END_OF_FILE) (gdb) 1683 DBUG_RETURN(result); (gdb) 1684 } (gdb) p result $5 = 146 error 146 is HA_ERR_LOCK_WAIT_TIMEOUT . If we hit this error, temp table "./test/t1#P#p0#TMP#", "./test/t1#P#p1#TMP#" are never dropped. The next call of ha_partition::change_partitions will hit dup key error when it tries to create the same temp table for the alter table partition operation. stack is ================================= #0 row_ins_duplicate_error_in_clust (cursor=0x45e7da00, entry=0x2aaaaada10b8, thr=0x2aaaaad9a1f0, mtr=0x45e7d530) at row/row0ins.c:1847 #1 0x000000000089f96f in row_ins_index_entry_low (mode=2, index=0x2aaaaad858b8, entry=0x2aaaaada10b8, ext_vec=0x0, n_ext_vec=0, thr=0x2aaaaad9a1f0) at row/row0ins.c:2039 #2 0x000000000089fdef in row_ins_index_entry (index=0x2aaaaad858b8, entry=0x2aaaaada10b8, ext_vec=0x0, n_ext_vec=0, thr=0x2aaaaad9a1f0) at row/row0ins.c:2180 #3 0x000000000089ffdf in row_ins_index_entry_step (node=0x2aaaaadb7d28, thr=0x2aaaaad9a1f0) at row/row0ins.c:2259 #4 0x00000000008a01d0 in row_ins (node=0x2aaaaadb7d28, thr=0x2aaaaad9a1f0) at row/row0ins.c:2391 #5 0x00000000008a03c7 in row_ins_step (thr=0x2aaaaad9a1f0) at row/row0ins.c:2501 #6 0x0000000000897028 in que_thr_step (thr=0x2aaaaad9a1f0) at que/que0que.c:1233 #7 0x0000000000897292 in que_run_threads_low (thr=0x2aaaaad9a1f0) at que/que0que.c:1319 #8 0x000000000089739d in que_run_threads (thr=0x2aaaaad9a1f0) at que/que0que.c:1355 #9 0x00000000008a2ee6 in row_create_table_for_mysql (table=0x2aaaaadbecb8, trx=0x2aaaaad990b8) at row/row0mysql.c:1897 #10 0x000000000083fdc3 in create_table_def (trx=0x2aaaaad990b8, ---Type <return> to continue, or q <return> to quit--- form=0x2aaaac007d98, table_name=0x45e7de70 "test/t1#P#p1#TMP#", path_of_temp_table=0x0, flags=1) at handler/ha_innodb.cc:5287 #11 0x0000000000840565 in ha_innobase::create (this=0x2aaaac006400, name=0x45e7e3f0 "./test/t1#P#p1#TMP#", form=0x2aaaac007d98, create_info=0x45e80310) at handler/ha_innodb.cc:5599 #12 0x00000000007596b3 in handler::ha_create (this=0x2aaaac006400, name=0x45e7e3f0 "./test/t1#P#p1#TMP#", form=0x2aaaac007d98, info=0x45e80310) at handler.cc:3368 #13 0x0000000000769fcd in ha_partition::prepare_new_partition ( this=0x2aaaac00a118, tbl=0x2aaaac007d98, create_info=0x45e80310, file=0x2aaaac006400, part_name=0x45e7e3f0 "./test/t1#P#p1#TMP#", p_elem=0x2aaaac0016e8) at ha_partition.cc:1225 #14 0x000000000076b3f3 in ha_partition::change_partitions ( this=0x2aaaac00a118, create_info=0x45e80310, path=0x45e7e790 "./test/t1", copied=0x45e7ed60, deleted=0x45e7ed68, pack_frm_data=0x0, pack_frm_len=0) at ha_partition.cc:1558 #15 0x0000000000759618 in handler::ha_change_partitions (this=0x2aaaac00a118, create_info=0x45e80310, path=0x45e7e790 "./test/t1", copied=0x45e7ed60, deleted=0x45e7ed68, pack_frm_data=0x0, pack_frm_len=0) at handler.cc:3405 #16 0x000000000052b996 in mysql_change_partitions (lpt=0x45e7ea30) at sql_partition.cc:5109 ================================= Again, similar with #47343, if we artificially drop the table when we hit the timeout: (gdb) call new_file_array[0]->ha_delete_table("./test/t1#P#p0#TMP#") $12 = 0 And if we are lucky that the table in background got dropped, we will not hit the dup key error. 100106 6:18:09 InnoDB: Dropped table test/t1#P#p0#TMP# in background drop queue. so if ha_partition::copy_partitions() fails, the temp table created in ha_partition::change_partitions() need to be dropped. Thanks Jimmy
[7 Jan 2010 13:25]
Calvin Sun
Mark as a dup of bug#47343. InnoDB returns the right error already.
[12 Mar 2010 14:12]
Bugs System
Pushed into 5.1.44-ndb-7.0.14 (revid:jonas@mysql.com-20100312135944-t0z8s1da2orvl66x) (version source revid:jonas@mysql.com-20100312115609-woou0te4a6s4ae9y) (merge vers: 5.1.44-ndb-7.0.14) (pib:16)
[12 Mar 2010 14:28]
Bugs System
Pushed into 5.1.44-ndb-6.2.19 (revid:jonas@mysql.com-20100312134846-tuqhd9w3tv4xgl3d) (version source revid:jonas@mysql.com-20100312060623-mx6407w2vx76h3by) (merge vers: 5.1.44-ndb-6.2.19) (pib:16)
[12 Mar 2010 14:44]
Bugs System
Pushed into 5.1.44-ndb-6.3.33 (revid:jonas@mysql.com-20100312135724-xcw8vw2lu3mijrhn) (version source revid:jonas@mysql.com-20100312103652-snkltsd197l7q2yg) (merge vers: 5.1.44-ndb-6.3.33) (pib:16)
