MySQL Bugs: #20090: InnoDB: Error: trying to declare trx to enter InnoDB

Bug #20090	InnoDB: Error: trying to declare trx to enter InnoDB
Submitted:	26 May 2006 14:18	Modified:	19 Jun 2010 0:07
Reporter:	Heikki Tuuri	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: InnoDB storage engine	Severity:	S2 (Serious)
Version:	5.0.xx	OS:	Linux (Linux)
Assigned to:	Vasil Dimov	CPU Architecture:	Any

Description:
Several users have reported these in the .err log:

060411 15:52:01 InnoDB: Error: trying to declare trx to enter InnoDB, but
InnoDB: it already is declared.

This may be associated with the replication thread.

How to repeat:
Do not know.

I received this error on my home pc last night:

061021 22:24:26  InnoDB: Started; log sequence number 0 2665997527
061021 22:24:26 [Note] /home/sbester/server/5.0/mysql-standard-5.0.26-linux-i686-glibc23/bin/mysqld: ready for connections.
Version: '5.0.26-standard'  socket: '/tmp/mysql.sock'  port: 3306  MySQL Community Edition - Standard (GPL)
061021 22:24:40  InnoDB: Error: trying to declare trx to enter InnoDB, but
InnoDB: it already is declared.
TRANSACTION 0 5332226, ACTIVE 0 sec, process no 1747, OS thread id 1250446256, thread declared inside InnoDB 0
mysql tables in use 1, locked 1
1 lock struct(s), heap size 320
MySQL thread id 4, query id 3 localhost 127.0.0.1 root update
INSERT IGNORE INTO `test`.`xxxx`( [...]

No replication was involved. Only thing was inserts into above table, followed by a select from same table. Only a single thread was accessing the db iirc.  will post more if I can reproduce the error.

Shane,

Do you have any ideas on how to repeat this situation?

For the first time in history, I was able to repeat this bug. If it turns out to be easily repeatable, we may finally find out the cause.

> heikki@127:~/test$ perl ibtest3 > out3 &
> [1] 12349
> heikki@127:~/test$ perl ibtest3a > out3a &
> [2] 12354
> heikki@127:~/test$ perl ibtest7 > out7 &
> [3] 12359
> heikki@127:~/test$ perl ibtest7a > out7a &
> [4] 12374
> heikki@127:~/test$ perl ibtest9 > out9 &
> [5] 12430
> heikki@127:~/test$ perl ibtest9a > out9a &
> [6] 12450
> heikki@127:~/test$ perl ibtest9b > out9b &
> [7] 12480
> heikki@127:~/test$
> heikki@127:~/test$
> heikki@127:~/test$
> heikki@127:~/test$ perl ibtest12 > out12 &
> [8] 12503
> heikki@127:~/test$ perl ibtest12a > out12a &
> [9] 12514
> heikki@127:~/test$ perl ibtest12b > out12b &
> [10] 12520
> 
> 
> 
> heikki@127:~/mysql-5.0/sql$
> heikki@127:~/mysql-5.0/sql$
> heikki@127:~/mysql-5.0/sql$ ./mysqld
> 061128 16:28:16 [Warning] Changed limits: max_open_files: 1024 
> max_connections: 886  table_cache: 64
> InnoDB: !!!!!!!!!!!!!! UNIV_DEBUG switched on !!!!!!!!!!!!!!!
> InnoDB: !!!!!!!!!!!!!! UNIV_SYNC_DEBUG switched on !!!!!!!!!!!!!!!
> InnoDB: !!!!!!!!!!!!!! UNIV_SEARCH_DEBUG switched on !!!!!!!!!!!!!!!
> InnoDB: !!!!!!!!!!!!!! UNIV_MEM_DEBUG switched on !!!!!!!!!!!!!!!
> 061128 16:28:16  InnoDB: Database was not shut down normally!
> InnoDB: Starting crash recovery.
> InnoDB: Reading tablespace information from the .ibd files...
> InnoDB: Restoring possible half-written data pages from the doublewrite
> InnoDB: buffer...
> 061128 16:28:16  InnoDB: Starting log scan based on checkpoint at
> InnoDB: log sequence number 0 37190707.
> InnoDB: Doing recovery: scanned up to log sequence number 0 37223632
> InnoDB: 1 transaction(s) which must be rolled back or cleaned up
> InnoDB: in total 920 row operations to undo
> InnoDB: Trx id counter is 0 10240
> 061128 16:28:17  InnoDB: Starting an apply batch of log records to the 
> database...
> InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 
> 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 
> 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 
> 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 
> 89 90 91 92 93 94 95 96 97 98 99
> InnoDB: Apply batch completed
> InnoDB: Last MySQL binlog file position 0 2398680, file name ./1.000023
> InnoDB: Starting in background the rollback of uncommitted transactions
> 061128 16:28:17  InnoDB: Rolling back trx with id 0 9487, 920 rows to undo
> 061128 16:28:18  InnoDB: Started; log sequence number 0 37223632
> 061128 16:28:18 [Note] Recovering after a crash using 1
> 061128 16:28:18 [Note] Starting crash recovery...
> 061128 16:28:18 [Note] Crash recovery finished.
> 061128 16:28:18 [Note] ./mysqld: ready for connections.
> Version: '5.0.32-debug-log'  socket: '/home/heikki/bugsocket'  port: 
> 3307  Source distribution
> 061128 16:29:53  InnoDB: Error: trying to declare trx to enter InnoDB, but
> InnoDB: it already is declared.
> TRANSACTION 0 10365, ACTIVE 0 sec, process no 12110, OS thread id 
> 1224276912, thread declared inside InnoDB 0
> mysql tables in use 1, locked 1
> 1 lock struct(s), heap size 336
> MySQL thread id 19, query id 14831 localhost heikki update
> insert into ibtest11b (D, B, C) values (5, 'khDkkkk' ,'khDkkkk')
> 
> 
> InnoDB: Rolling back of trx id 0 9487 completed
> 061128 16:30:56  InnoDB: Rollback of non-prepared transactions completed

Strange: the 'if' below sees trx->declared_to_be_inside_innodb true, but in the printout it is 0. As if two threads were using the same trx, and one of them resets the flag to 0 before the other prints it!

void
srv_conc_enter_innodb(
/*==================*/
        trx_t*  trx)    /* in: transaction object associated with the
                        thread */
{
        ibool                   has_slept = FALSE;
        srv_conc_slot_t*        slot      = NULL;
        ulint                   i;

        /* If trx has 'free tickets' to enter the engine left, then use one
        such ticket */

        if (trx->n_tickets_to_enter_innodb > 0) {
                trx->n_tickets_to_enter_innodb--;

                return;
        }

        os_fast_mutex_lock(&srv_conc_mutex);
retry:
        if (trx->declared_to_be_inside_innodb) {
                ut_print_timestamp(stderr);
                fputs(
"  InnoDB: Error: trying to declare trx to enter InnoDB, but\n"
"InnoDB: it already is declared.\n", stderr);
                trx_print(stderr, trx, 0);
                putc('\n', stderr);
                os_fast_mutex_unlock(&srv_conc_mutex);

                ut_error;

                return;
        }

I was able to repeat inside gdb.

061130 18:20:55InnoDB: Assertion failure in thread 1220651952 in file srv0srv.c line 1012
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.0/en/forcing-recovery.html
InnoDB: about forcing recovery.
InnoDB: Thread 1219791792 stopped in file ha_innodb.cc line 766
InnoDB: Thread 1219201968 stopped in file ../include/sync0sync.ic line 189

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1220651952 (LWP 13397)]
0x0846e672 in srv_conc_enter_innodb (trx=0x4891e718) at srv0srv.c:1012
1012                    ut_error;
Current language:  auto; currently c
(gdb) bt
#0  0x0846e672 in srv_conc_enter_innodb (trx=0x4891e718) at srv0srv.c:1012
#1  0x08318c9c in innodb_srv_conc_enter_innodb (trx=0x4891e718)
    at ha_innodb.cc:342
#2  0x083120fa in ha_innobase::write_row (this=0x4893c9c0,
    record=0x48988658 "ø\001") at ha_innodb.cc:3269
#3  0x08294b0d in write_record (thd=0x48960f80, table=0x489fbc68,
    info=0x48c19d80) at sql_insert.cc:1212
#4  0x082933b2 in mysql_insert (thd=0x48960f80, table_list=0x48f18af8,
    fields=@0x489614b4, values_list=@0x489614d8, update_fields=@0x489614cc,
    update_values=@0x489614c0, duplic=DUP_ERROR, ignore=false)
    at sql_insert.cc:591
#5  0x08231f93 in mysql_execute_command (thd=0x48960f80) at sql_parse.cc:3391
#6  0x08238a64 in mysql_parse (thd=0x48960f80,
    inBuf=0x48f18980 "insert into ibtest09 (D, B, C, F, G, H, I) values (5, 'kjgclgrtfuylfluyfyufyulfulfyyulofuyolfyufyufuyfyufyufyufyufyyufujhfghd", 'k' <repeats 14 times>, "' ,'kjgclgrtfuylfluyfyufyulfulfyyulofuyolfyufyufuyfyufyufyufy"..., length=252) at sql_parse.cc:5825
#7  0x0822ddcd in dispatch_command (command=COM_QUERY, thd=0x48960f80,
    packet=0x489892f9 "insert into ibtest09 (D, B, C, F, G, H, I) values (5, 'kjgclgrtfuylfluyfyufyulfulfyyulofuyolfyufyufuyfyufyufyufyufyyufujhfghd", 'k' <repeats 14 times>, "' ,'kjgclgrtfuylfluyfyufyulfulfyyulofuyolfyufyufuyfyufyufyufy"..., packet_length=253) at sql_parse.cc:1773
#8  0x0822d51d in do_command (thd=0x48960f80) at sql_parse.cc:1557
#9  0x0822c607 in handle_one_connection (arg=0x93ebf68) at sql_parse.cc:1188
#10 0x40041b63 in start_thread () from /lib/tls/libpthread.so.0
#11 0x4018718a in clone () from /lib/tls/libc.so.6
(gdb) print *trx
$1 = {magic_n = 91118598, op_info = 0x8798ce6 "", type = 1, conc_state = 2,
  start_time = 1164903655, isolation_level = 2, check_foreigns = 1,
  check_unique_secondary = 1, id = {high = 0, low = 30837}, xid = {
    formatID = -1, gtrid_length = 0, bqual_length = 0,
    data = '\0' <repeats 127 times>}, support_xa = 1, no = {high = 4294967295,
    low = 4294967295}, flush_log_later = 0, must_flush_log_later = 0,
  commit_lsn = {high = 3199909562, low = 3200170686}, dict_operation = 0,
  table_id = {high = 3132799678, low = 3200170686}, active_trans = 1,
  mysql_thd = 0x48960f80, mysql_query_str = 0x4896177c,
  mysql_log_file_name = 0x0, mysql_log_offset = 0,
  mysql_master_log_file_name = 0x87a8081 "", mysql_master_log_pos = 0,
  repl_wait_binlog_name = 0x0, repl_wait_binlog_pos = 0,
  mysql_thread_id = 1220651952, mysql_process_no = 13339,
  n_mysql_tables_in_use = 1, mysql_n_tables_locked = 1,
  dict_operation_lock_mode = 0, has_search_latch = 0,
  search_latch_timeout = 10000, declared_to_be_inside_innodb = 1,
  n_tickets_to_enter_innodb = 0, auto_inc_lock = 0x489628e8, new_rec_locks = {
    0x0, 0x0}, trx_list = {prev = 0x489fc8d8, next = 0x9241fd0},
  mysql_trx_list = {prev = 0x489fc8d8, next = 0x9492a88}, error_state = 10,
  error_info = 0xbebebaba, sess = 0x422406f0, que_state = 1, graph = 0x0,
  n_active_thrs = 0, handling_signals = 0,
  graph_before_signal_handling = 0xbebebaba, sig = {type = 3199909566,
    state = 3132799678, sender = 3132799674, receiver = 0xbabebabe, savept = {
      least_undo_no = {high = 3199908542, low = 3199909566}}, signals = {
      prev = 0xbebebaba, next = 0xbebabebe}, reply_signals = {
      prev = 0xbebababa, next = 0xbabababa}}, signals = {count = 0,
    start = 0x0, end = 0x0}, reply_signals = {count = 0, start = 0x0,
    end = 0x0}, wait_lock = 0x0, was_chosen_as_deadlock_victim = 0,
  wait_started = 1164903655, wait_thrs = {count = 0, start = 0x0, end = 0x0},
  deadlock_mark = 0, lock_heap = 0x489628a0, trx_locks = {count = 1,
    start = 0x489628e8, end = 0x489628e8}, global_read_view_heap = 0x48920c58,
  global_read_view = 0x0, read_view = 0x0, trx_savepoints = {count = 0,
    start = 0x0, end = 0x0}, undo_mutex = {event = 0x4891ba48, lock_word = 0,
    os_fast_mutex = {global = {__m_reserved = 0, __m_count = 0,
        __m_owner = 0x0, __m_kind = 2, __m_lock = {__status = 0,
          __spinlock = 0}}, mutex = {__m_reserved = 0, __m_count = 0,
        __m_owner = 0x0, __m_kind = 3, __m_lock = {__status = 0,
          __spinlock = 0}}, file = 0x87bdc36 "os0sync.c", line = 623,
      count = 0, thread = 0}, waiters = 0, list = {prev = 0x48994cec,
      next = 0x9492c78}, file_name = 0x87ba007 "not yet reserved", line = 0,
    thread_id = 3200170686, level = 700, cfile_name = 0x87a804b "trx0trx.c",
    cline = 147, magic_n = 979585, count_os_wait = 0, count_using = 0,
    count_spin_loop = 0, count_spin_rounds = 0, count_os_yield = 0,
    lspent_time = 0, lmax_spent_time = 0,
    cmutex_name = 0x87a8082 "&(trx->undo_mutex)", mutex_type = 0}, undo_no = {
    high = 0, low = 0}, last_sql_stat_start = {least_undo_no = {high = 0,
      low = 0}}, rseg = 0x92120c8, insert_undo = 0x0, update_undo = 0x0,
  roll_limit = {high = 3200170686, low = 3200171710},
  pages_undone = 3200170686, undo_no_arr = 0x0,
  detailed_error = "\000¾¾¾ºº¾¾º¾ºººº¾º¾º¾º¾ºº¾¾º¾¾¾º¾º¾ººººº¾¾¾¾¾ºº¾¾ººº¾º¾º¾¾ºº¾¾¾º¾¾¾¾ºº¾¾¾¾¾ººº¾¾º¾¾º¾º¾º¾¾ººº¾¾¾¾ººº¾º¾¾º¾ºººº¾¾º¾º¾¾¾¾ºº¾ºº¾ºº¾¾¾º¾¾º¾¾¾¾¾¾ºº¾ºººº¾ºº¾ºº¾¾¾¾¾¾º¾¾ººººº¾¾¾º¾ººººº¾¾¾ºº¾º¾¾¾¾¾¾¾¾¾º¾ºººººº¾"...}
(gdb) info threads
  31 Thread 1223097264 (LWP 13439)  0x40172347 in sched_yield ()
   from /lib/tls/libc.so.6
  30 Thread 1222900656 (LWP 13438)  0x40044295 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0
  29 Thread 1222704048 (LWP 13437)  0x40044295 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0
  28 Thread 1222507440 (LWP 13436)  0x40044295 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0
  27 Thread 1222310832 (LWP 13433)  0x40044295 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0
  26 Thread 1220848560 (LWP 13431)  0x40046436 in __lll_mutex_lock_wait ()
   from /lib/tls/libpthread.so.0
  25 Thread 1222114224 (LWP 13429)  0x40046436 in __lll_mutex_lock_wait ()
   from /lib/tls/libpthread.so.0
  24 Thread 1221917616 (LWP 13428)  0x40044295 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0
* 23 Thread 1220651952 (LWP 13397)  0x0846e672 in srv_conc_enter_innodb (

I was wrong in my analysis. The printout tells the number of 'TICKETS', not the value of the flag trx->declared_to_be_inside_innodb.

        if (trx->declared_to_be_inside_innodb) {
                fprintf(f, ", thread declared inside InnoDB %lu",
                               (ulong) trx->n_tickets_to_enter_innodb);
        }

The bug found: if in ::write_row(), there is a lock wait on the AUTO-INC lock, then we have NOT 'declared the thread inside InnoDB' BUT at the end of the lock wait it will be declared. Then, in the actual row insertion InnoDB will complain that the thread is already declared inside InnoDB.

I need to check if this can cause a hang, as it will temporarily cause the thread count to exceed the maximum.

Also, I need to check if there are other similar places as ::write_row().

The bug NOT found: srv_suspend_mysql_thread() does take into account if the thread was declared inside InnoDB or not.

The bug might be due to the code in ha_innobase::innobase_read_and_init_auto_inc(). It causes unusual execution paths, for example, if there is a lock wait.

Yes, this code would leave trx in a state where we see it in gdb:

/*************************************************************************
This lets a thread enter InnoDB regardless of the number of threads inside
InnoDB. This must be called when a thread ends a lock wait. */

void
srv_conc_force_enter_innodb(
/*========================*/
        trx_t*  trx)    /* in: transaction object associated with the
                        thread */
{
        if (UNIV_LIKELY(!srv_thread_concurrency)) {

                return;
        }

        os_fast_mutex_lock(&srv_conc_mutex);

        srv_conc_n_threads++;
        trx->declared_to_be_inside_innodb = TRUE;
        trx->n_tickets_to_enter_innodb = 0;

        os_fast_mutex_unlock(&srv_conc_mutex);
}

and that would cause the print in srv_conc_enter() when do the actual insert.

The bug is benign.

Fix: Changing the above to:

       trx->n_tickets_to_enter_innodb = 1;

should fix this. Then a lock wait that happens outside the srv_conc_enter() ... srv_conc_exit() for a thread that is 'declared inside InnoDB' will leave trx in a state that is consistent when we the next time call srv_conc_enter().

I get this error each time when I starting/restarting mysqld. I have only one big table using innodb with many concurrent inserts/updates/deletes. It fysically located on other HDD than MyISAM tables.

Error log entry:

070213  6:56:31  InnoDB: Started; log sequence number 1 1962367788
070213  6:56:31 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.0.26-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  Gentoo Linux mysql-5.0.26-r2
070213  6:56:32  InnoDB: Error: trying to declare trx to enter InnoDB, but
InnoDB: it already is declared.
TRANSACTION 0 11392261, ACTIVE 0 sec, process no 1824, OS thread id 2265508768, thread declared inside InnoDB 0
mysql tables in use 1, locked 1
1 lock struct(s), heap size 320
MySQL thread id 1, query id 7 r7d221.webazilla.com 88.85.65.153 aemain update
INSERT INTO rs_fhg_stat SET fhg_id = 2568, wm_id = 968, ref = 'http://wwww.3dporno.tv/', dat = NOW()

-------------------------------------------
# mysql --version
mysql  Ver 14.12 Distrib 5.0.26, for pc-linux-gnu (i386) using readline 5.1

# uname -a
Linux localhost 2.6.18-gentoo-r6 #1 SMP Thu Jan 25 20:01:32 Local time zone must be set--see zic  i686 Intel(R) Xeon(TM) CPU 3.00GHz GNU/Linux

my.cnf:
[mysqld]
character-set-server            = utf8
default-character-set           = utf8
user                                            = mysql
port                                            = 3306
socket                                          = /var/run/mysqld/mysqld.sock
pid-file                                        = /var/run/mysqld/mysqld.pid
log-error                                       = /var/log/mysql/mysqld.err
basedir                                         = /usr
datadir                                         = /var/lib/mysql
skip-locking

key_buffer = 300M
max_allowed_packet = 1M
table_cache = 512
sort_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 8M
myisam_sort_buffer_size = 64M
ft_min_word_len = 3
ft_max_word_len = 84
thread_cache_size = 8
query_cache_size = 96M
max_connections = 700
max_connect_errors=10000
# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 8
net_buffer_length                       = 32K
expire_logs_days = 10
language                                        = /usr/share/mysql/english
log_error = /var/log/mysql/error.log
log_warnings = 1
log-bin = /vint2/binary/hawk2
server-id                                       = 1
innodb_buffer_pool_size = 256M
innodb_additional_mem_pool_size = 20M
innodb_data_home_dir            = /vint2/innodb/
innodb_log_arch_dir             = /vint2/innodb/
innodb_log_group_home_dir       = /vint2/innodb/
innodb_data_file_path = ibdata1:500M:autoextend
innodb_log_file_size = 250M
innodb_log_buffer_size = 8M
set-variable = innodb_log_files_in_group=2
innodb_flush_log_at_trx_commit = 1
innodb_lock_wait_timeout = 50

Heikki, any thoughts on when this patch may arrive in the server? Not urgent, just checking.

Assigning this to Vasil. The fix is explained above. The main job is to run enough high-concurrency tests, mainly with innodb_thread_concurrency=1 or 2 in my.cnf, so that we see it does not hang after this fix.
--Heikki

There is similar Bug #29681

I haven't marked Bug #29681 as duplicate of this one, because is not clear if cause of these 2 bug reports is same.

Queued to 5.1-maint team tree

Pushed into 5.1.21-beta

will this be fixed in 5.0.x ?

It is fixed in the InnoDB 5.0 SVN tree under r1552. This snapshot has not yet been sent. The last one is r1547, so it will come with the next 5.0 snapshot.

Noted in 5.1.21 changelog.

InnoDB produced an unnecessary (and harmless) warning:

InnoDB: Error: trying to declare trx to enter InnoDB, but InnoDB: it already declared.

Resetting report to Patch pending due to pending 5.0.x fix.

Queued to 5.0-maint

Pushed into 5.0.48

Pushed into 5.1.22-beta

Noted in 5.0.48 changelog.

See bug: http://bugs.mysql.com/bug.php?id=43470.

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)

Push resulted from incorporation of InnoDB tree. No changes pertinent to this bug. Re-closing.

Pushed into mysql-next-mr (revid:alik@sun.com-20100524190136-egaq7e8zgkwb9aqi) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (pib:16)

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)

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)

Push resulted from incorporation of InnoDB tree. No changes pertinent to this bug.
Re-closing.

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)

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)

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)