Bug #15650 DELETE with LEFT JOIN crashes server with innodb_locks_unsafe_for_binlog
Submitted: 10 Dec 2005 8:11 Modified: 18 Jun 2010 22:49
Reporter: Corin Langosch Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: InnoDB storage engine Severity:S1 (Critical)
Version:5.0.16, 5.0.18, 5.0.19 OS:Linux (debian linux amd64)
Assigned to:
Tags: crash, innodb_locks_unsafe_for_binlog

[10 Dec 2005 8:11] Corin Langosch
Description:
MySQL thread id 11165316, query id 44551208 217.68.156.8 gimy_mails Sending data

DELETE ml.* FROM mail_l AS ml LEFT JOIN mail_mails AS mm ON (mm.id=ml.mail_id) WHERE mm.id IS NULL

051210  3:09:16InnoDB: Assertion failure in thread 1165568352 in file btr0pcur.c line 216

server crahes. this does not happen with this query only, also zwo similar queries (delete from xx LEFT JOIN xx ON (xx) WHERE xx IS NULL) crash. all tables are innodb compact.

bug also present on i686!
 

How to repeat:
!!please see attached file for test case creation data!!

DELETE ml.* FROM mail_l AS ml LEFT JOIN mail_mails AS mm ON (mm.id=ml.mail_id) WHERE mm.id IS NULL;

#2013 - Lost connection to MySQL server during query
[10 Dec 2005 8:11] Corin Langosch
creates 2 tables with some data

Attachment: mysql_bug_testcase.sql (text/x-sql), 15.36 KiB.

[10 Dec 2005 16:59] Valerii Kravchuk
Thank you for a crash report. Sorry, but I was not able to repeat it with your data neither on 5.0.15-nt, nor on 5.0.18-BK build on Linux:

...
mysql> INSERT INTO `mail_mails` (`id`, `sender_id`, `subject`, `body`, `create_stamp`) VALUES (62, 0, '', '', 1133614484);
INSQuery OK, 1 row affected (0.01 sec)

mysql> INSERT INTO `mail_mails` (`id`, `sender_id`, `subject`, `body`, `create_stamp`) VALUES (63, 0, '', '', 1133618077);
Query OK, 1 row affected (0.01 sec)

mysql> DELETE ml.* FROM mail_l AS ml LEFT JOIN mail_mails AS mm ON (mm.id=ml.mail_id)
    -> WHERE mm.id IS NULL;
Query OK, 0 rows affected (0.01 sec)

mysql> select version();
+-----------+
| version() |
+-----------+
| 5.0.18    |
+-----------+
1 row in set (0.00 sec)

I see no problems for this statement any way, because you really have 0 rows with NULL id in mail_mails table in your file...

You had crash, so there should be a stack trace in the error log. Would you, please, try to resolve it and send the results? Describe your debian system also: kernel version, glibc version etc. There were a lot of crashes on Debian on amd64 bit just because of a bug in glibc used.

Finally, please, inform is it a fresh installation or you upgraded from the previous 4.x version?
[10 Dec 2005 18:31] Corin Langosch
please see attached file for errorlog. the errorlog is from the following system:
Linux devel 2.6.12-1-686 #1 Tue Sep 27 12:52:50 JST 2005 i686 GNU/Linux

as said, it happens on i686 AND amd64.

the reason the tables contains no null values does NOT mean is does not delete something, as the query looks for rows in one table not matching rows in the other table and deletes those.

please try to repeat with 5.0.16. may be it's already fixed in 5.0.18? where can i get it, 5.0.17 isn't even released yet. :-(
[10 Dec 2005 18:32] Corin Langosch
errrlog from i686

Attachment: mysql_bug.txt (text/plain), 4.11 KiB.

[11 Dec 2005 11:38] Victoria Reznichenko
I wasn't able to repeat crash on AMD 64 box too with MySQL 5.0.16
[11 Dec 2005 12:06] Heikki Tuuri
Hi!

For some reason, the persistent cursor does not have a stored position. This might be a bug in MySQL's table locking, or in the way it calls handler routines.

I am assigning this to Osku for a detailed study. It did print a hex dump of the cursor object, and also the trx involved. We have lots of data to analyze.

Regards,

Heikki

ibool
btr_pcur_restore_position(
/*======================*/
                                        /* out: TRUE if the cursor position
                                        was stored when it was on a user record
                                        and it can be restored on a user record
                                        whose ordering fields are identical to
                                        the ones of the original user record */
        ulint           latch_mode,     /* in: BTR_SEARCH_LEAF, ... */
        btr_pcur_t*     cursor,         /* in: detached persistent cursor */
        mtr_t*          mtr)            /* in: mtr */
{
        dict_tree_t*    tree;
        page_t*         page;
        dtuple_t*       tuple;
        ulint           mode;
        ulint           old_mode;
        mem_heap_t*     heap;

        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, (const byte*)cursor, sizeof(btr_pcur_t));
                if (cursor->trx_if_known) {
                        trx_print(stderr, cursor->trx_if_known, 0);
                }

                ut_error;
        }
[12 Dec 2005 16:27] Heikki Tuuri
Hi!

What is your my.cnf like?

Are you using innodb_locks_unsafe_for_binlog?

The transaction print shows that the thread is doing ::unlock_row().

The hex dump shows that pcur->old_stored == BTR_PCUR_OLD_NOT_STORED, that is why the assertion fails.

Regards,

Heikki

/*************************************************************************
This can only be used when srv_locks_unsafe_for_binlog is TRUE. Before
calling this function we must use trx_reset_new_rec_lock_info() and
trx_register_new_rec_lock() to store the information which new record locks
really were set. This function removes a newly set lock under prebuilt->pcur,
and also under prebuilt->clust_pcur. Currently, this is only used and tested
in the case of an UPDATE or a DELETE statement, where the row lock is of the
LOCK_X type.
Thus, this implements a 'mini-rollback' that releases the latest record
locks we set. */

int
row_unlock_for_mysql(
/*=================*/
                                        /* out: error code or DB_SUCCESS */
        row_prebuilt_t* prebuilt,       /* in: prebuilt struct in MySQL
                                        handle */
        ibool           has_latches_on_recs)/* TRUE if called so that we have
                                        the latches on the records under pcur
                                        and clust_pcur, and we do not need to
                                        reposition the cursors. */
{
        dict_index_t*   index;
        btr_pcur_t*     pcur            = prebuilt->pcur;
        btr_pcur_t*     clust_pcur      = prebuilt->clust_pcur;
        trx_t*          trx             = prebuilt->trx;
        rec_t*          rec;
        mtr_t           mtr;

        ut_ad(prebuilt && trx);
        ut_ad(trx->mysql_thread_id == os_thread_get_curr_id());

        if (!srv_locks_unsafe_for_binlog) {

                fprintf(stderr,
"InnoDB: Error: calling row_unlock_for_mysql though\n"
"InnoDB: srv_locks_unsafe_for_binlog is FALSE.\n");

                return(DB_SUCCESS);
        }

        trx->op_info = "unlock_row";

        index = btr_pcur_get_btr_cur(pcur)->index;

        if (index != NULL && trx_new_rec_locks_contain(trx, index)) {

                mtr_start(&mtr);

                /* Restore the cursor position and find the record */

                if (!has_latches_on_recs) {
                        btr_pcur_restore_position(BTR_SEARCH_LEAF, pcur, &mtr);
                }
[12 Dec 2005 22:37] Corin Langosch
hi!

yes, innodb_locks_unsafe_for_binlog is enabled!
anyway it must not crash? :)

regards,
corin
[13 Dec 2005 7:20] Jan Lindström
I could repeat this bug using innobase_locks_unsafe_for_binlog option and 5.0.17. Here some output from gdb:

#0  0x0835afb4 in btr_pcur_restore_position (latch_mode=1, cursor=0xb7b13b68, mtr=0x9081bea8) at btr0pcur.c:216
#1  0x08335c0e in row_unlock_for_mysql (prebuilt=0xb7b15468, has_latches_on_recs=0) at row0mysql.c:1484
#2  0x08292636 in ha_innobase::unlock_row (this=0x8c979c8) at ha_innodb.cc:3830
#3  0x08206c7d in evaluate_join_record (join=0x8c8bac0, join_tab=0x8c98aa0, error=0, report_error=0x8c7211c "")
    at sql_select.cc:9711
#4  0x08206fa7 in sub_select (join=0x8c8bac0, join_tab=0x8c98aa0, end_of_records=false) at sql_select.cc:9582
#5  0x08206c0c in evaluate_join_record (join=0x8c8bac0, join_tab=0x8c98930, error=0, report_error=0x8c7211c "")
    at sql_select.cc:9697
#6  0x08206fa7 in sub_select (join=0x8c8bac0, join_tab=0x8c98930, end_of_records=false) at sql_select.cc:9582
#7  0x08207300 in do_select (join=0x8c8bac0, fields=0x8c719bc, table=0x0, procedure=0x0) at sql_select.cc:9345
#8  0x0821a1bd in JOIN::exec (this=0x8c8bac0) at sql_select.cc:1686
#9  0x0821a534 in mysql_select (thd=0x8c716c0, rref_pointer_array=0x8c71a58, tables=0x8c8b120, wild_num=0,
    fields=@0x8c719bc, conds=0x8c8b988, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0,
    select_options=3498330752, result=0x8c8ba80, unit=0x8c71710, select_lex=0x8c71938) at sql_select.cc:1850
#10 0x081bc3d1 in mysql_execute_command (thd=0x8c716c0) at sql_parse.cc:3383
#11 0x081c1c11 in mysql_parse (thd=0x8c716c0,
    inBuf=0x8c8ae90 "DELETE ml.* FROM mail_l AS ml LEFT JOIN mail_mails AS mm ON (mm.id=ml.mail_id)\nWHERE mm.id IS NULL", length=98) at sql_parse.cc:5620
#12 0x081c265b in dispatch_command (command=COM_QUERY, thd=0x8c716c0,
    packet=0x8c86e59 "DELETE ml.* FROM mail_l AS ml LEFT JOIN mail_mails AS mm ON (mm.id=ml.mail_id)\nWHERE mm.id IS NULL", packet_length=99) at sql_parse.cc:1710
#13 0x081c3c0f in do_command (thd=0x8c716c0) at sql_parse.cc:1511
#14 0x081c4018 in handle_one_connection (arg=0x8c716c0) at sql_parse.cc:1155
#15 0xb7f00361 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#16 0xb7e31bde in clone () from /lib/tls/i686/cmov/libc.so.6

I used test case and database provided earlier. Raised priority to P2 because this is a crash bug.

Regards,
    Jan
[13 Dec 2005 7:44] Jan Lindström
More outputs from gdb before MySQL calls unlock_row which causes a assert crash.

Attachment: gdb2.txt (text/plain), 14.72 KiB.

[13 Dec 2005 12:39] Jan Lindström
Corin,

Could you pleas provide those other two deletes with left join which crashed the server. I have proposed a fix for this bug but I need to test that all versions that crashed really work now.

Regards,
    Jan
[13 Dec 2005 14:06] Heikki Tuuri
We need to change:

            || prebuilt->select_lock_type == LOCK_X

to:

             || prebuilt->select_lock_type != LOCK_NONE

on about line 3980 of row0sel.c
[13 Dec 2005 14:11] Corin Langosch
the following queries crash with the supplied data

DELETE d.* FROM domains AS d LEFT JOIN a_pos AS ap ON (d.ap_id=ap.id) WHERE ap.id IS NULL;

DELETE a.* FROM auftraege AS a LEFT JOIN kunden AS k ON (k.id=a.owner_id) WHERE k.id IS NULL;

DELETE ap.* FROM a_pos AS ap LEFT JOIN auftraege AS a ON (a.id=ap.a_id) WHERE a.id IS NULL;
[17 Dec 2005 13:07] Corin Langosch
hi!

is the bug fixed in 5.0.17? 
i didn't see it in the changelog.. :-(

regards,
corin
[21 Dec 2005 7:36] Jan Lindström
No bug is not fixed on 5.0.17. Fix for this patch is still on review.

Regards,
    Jan
[17 Jan 2006 16:21] Alexander Ivanov
Fixed in 5.0.19.
[18 Jan 2006 0:16] Mike Hillyer
Added to 5.0.19 changelog:

 <listitem>
        <para>
          A <literal>DELETE</literal> statement involving a
          <literal>LEFT JOIN</literal> and an <literal>IS NULL</literal>
          test on the right-hand table of the join crashed the server
          when the <literal>innodb_locks_unsafe_for_binlog</literal>
          option was enabled. (Bug #15650)
        </para>
      </listitem>
[27 Mar 2006 8:44] Shane Bester
regarding the messages [ERROR] mysqld-debug.exe: Can't find file: '.\xxxx\yyy.frm' (errno: 9) from 5.0.19, no other process accesses the files, no antivirus, no sharing, no disk problems, and the tables aren't corrupted/locked on filesystem..

Only the x64 binaries produce that message with testcase. 32-bit binaries didn't.
[27 Mar 2006 12:54] Heikki Tuuri
Hi!

Looks like MySQL calls unlock_row() also in a plain consistent read SELECT:

060325 23:30:04  InnoDB: Error: unlock row could not find a 0 mode lock on the record
060325 23:30:04  InnoDB: Error: unlock row could not find a 0 mode lock on the record
060325 23:30:04  InnoDB: Error: unlock row could not find a 0 mode lock on the record
 len 224; hex 1831690c00000000e513dc0c000000000100000000000000504de00a0000000003000000000000000100000000000000000000000000000000000000000000000100000000000000000000000000000008050000000000000800000000000000000000000000000000000000000000000100000000000000834451070000000000000000000000000600000000000000080500000000000008000000000000000000000000000000000000000000000060e1117700000000040000000000000018991d0b00000000cdcdcdcdcdcdcdcd0000000000000000cdcdcdcdcdcdcdcd; asc  1i     å Ü             PMà                                                                                             ƒDQ                                                     `á w                    ÍÍÍÍÍÍÍÍ        ÍÍÍÍÍÍÍÍ;TRANSACTION 0 172767, ACTIVE 0 sec, OS thread id 2164 unlock_row
mysql tables in use 1, locked 0
MySQL thread id 18, query id 590652 localhost 127.0.0.1 root Sorting result
select RuleID from swrules2 where (TriggerType = ?) AND (SubtypeID = ?) order by Priority
060325 23:30:06InnoDB: Assertion failure in thread 2164 in file .\btr\btr0pcur.c line 216
InnoDB: We intentionally generate a memory trap.

Regards,

Heikki
[27 Mar 2006 13:10] Heikki Tuuri
Fix: in the function below, return immediately if prebuilt->select_lock_type == LOCK_NONE.

It is surprising that a fundamental InnoDB bug like this was found this late! Looks like trx_new_rec_lock_info happened to be zero almost always, and it masked this bug.

ha_innodb.cc:

/**************************************************************************
Removes a new lock set on a row. This method does nothing unless the
option innodb_locks_unsafe_for_binlog is set.*/

void
ha_innobase::unlock_row(void)
/*=========================*/
{
        row_prebuilt_t* prebuilt = (row_prebuilt_t*) innobase_prebuilt;

        DBUG_ENTER("ha_innobase::unlock_row");

        if (last_query_id != user_thd->query_id) {
                ut_print_timestamp(stderr);
                sql_print_error("last_query_id is %lu != user_thd_query_id is "
                                "%lu", (ulong) last_query_id,
                                (ulong) user_thd->query_id);
                mem_analyze_corruption((byte *) prebuilt->trx);
                ut_error;
        }

        if (srv_locks_unsafe_for_binlog) {
                row_unlock_for_mysql(prebuilt, FALSE);
        }

        DBUG_VOID_RETURN;

}

Thank you,

Heikki
[29 Mar 2006 12:20] Jan Lindström
Applied to 5.0 and 5.1 on InnoDB internal svn.

Regards,
    Jan
[31 Mar 2006 15:54] 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/4370
[5 Apr 2006 19:20] Elliot Murphy
Fixed in InnoDB snapshot398; fixes are in for 5.0.21
[11 Apr 2006 3:09] Paul Dubois
Noted in 5.0.21 changelog.

<literal>DELETE</literal> with <literal>LEFT JOIN</literal>
for <literal>InnoDB</literal> tables could crash the server if<literal>innodb_locks_unsafe_for_binlog</literal> was enabled.
(Bug #15650)
[24 Feb 2009 9:52] River Tarnell
i'm seeing this bug--or one that looks *very* similar--in 5.1.30 and 5.1.31 on Solaris 10.  from the error log:

Version: '5.1.30'  socket: '/tmp/mysql.sock'  port: 3306  Source distribution
090224  8:36:42 [ERROR] /opt/TSmysql/lib/mysqld: Table './p_wikiword/full_de_log' is marked as crashed and should be repaired
090224  8:36:42 [Warning] Checking table:   './p_wikiword/full_de_log'
090224  8:36:42 [Warning] Recovering table: './p_wikiword/full_de_log'
 len 224; hex d812db02000000004dc1cb21000000000000000000000000000000000000000003000000000000000300000000000000000000000000000003000000000000000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000100000000000000834451070000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000060e11177000000000400000000000000d8f6da0200000000000000000000000000000000000000000000000000000000; asc         M  !                                                                                                             DQ                                                     `  w                                            ;TRANSACTION 0 5632, ACTIVE 0 sec, OS thread id 12 unlock_row, thread declared inside InnoDB 499
mysql tables in use 2, locked 2
5 lock struct(s), heap size 1216, 2 row lock(s)
MySQL thread id 1, query id 49 localhost 127.0.0.1 wikiword Sending data
/* deleteLinksToBadResources */ DELETE FROM full_de_alias USING full_de_alias JOIN full_de_resource ON full_de_alias.target_name = full_de_resource.name WHERE full_de_resource.type IN (30, 40, 100, 20)
090224  8:36:51  InnoDB: Assertion failure in thread 12 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.
090224  8:36:51 - mysqld got signal 11 ;

innodb_locks_unsafe_for_binlog is enabled.  after disabling it, the server no longer crashes.  upgraded to 5.1.31, no change; the error is identical.
[24 Feb 2009 10:47] Shane Bester
i have bug #39320 opened for 5.1.30, but so far no testcase..
[24 Feb 2009 22:26] River Tarnell
tried to reproduce this on my test system (HP-UX) with 5.1.31.  instead of crashing, MySQL seemed to deadlock or hang with the following stack trace:

#0  0xc0000000004fc12c in _select_sys+0x2c () from /usr/lib/pa20_64/libc.2
#1  0xc00000000050779c in select+0xf4 () from /usr/lib/pa20_64/libc.2
#2  0x40000000006ef2e8 in os_thread_sleep+0x68 ()
#3  0x4000000000732180 in ut_dbg_stop_thread+0x70 ()
#4  0x400000000073b88c in btr_pcur_restore_position+0x44c ()
#5  0x40000000007059e0 in row_unlock_for_mysql+0x158 ()
#6  0x400000000068ce4c in ha_innobase::unlock_row+0x74 ()
#7  0x400000000053ee80 in evaluate_join_record+0x268 ()
#8  0x400000000053eb90 in sub_select+0x118 ()
#9  0x400000000053ed74 in evaluate_join_record+0x15c ()
#10 0x400000000053eb90 in sub_select+0x118 ()
#11 0x400000000053e6a0 in do_select+0x180 ()
#12 0x4000000000528bd8 in JOIN::exec+0x1da0 ()
#13 0x40000000005295a8 in mysql_select+0x740 ()
#14 0x40000000004b2fd8 in mysql_execute_command+0x3200 ()
#15 0x40000000004b99f0 in mysql_parse+0x188 ()
#16 0x40000000004ae878 in dispatch_command+0xb70 ()
#17 0x40000000004adbf0 in do_command+0x160 ()
#18 0x40000000004ac554 in handle_one_connection+0x21c ()
#19 0xc00000000005c290 in __pthread_body+0x50 () from /usr/lib/pa20_64/libpthread.1
#20 0xc000000000066c44 in __pthread_start+0x14 () from /usr/lib/pa20_64/libpthread.1
[24 Feb 2009 22:32] River Tarnell
uploaded test case: ftp.mysql.com:/pub/mysql/upload/15650-wikiword.sql.gz.  contains two tables: full_de_alias and full_de_source.  import, then run this query:

DELETE FROM full_de_alias USING full_de_alias JOIN
full_de_resource ON full_de_alias.target_name = full_de_resource.name WHERE
full_de_resource.type IN (30, 40, 100, 20);

the server should crash.
[25 Feb 2009 19:55] Shane Bester
I could repeat the crash using the testcase provided by River. Will try make a reduced version of the dataset needed.

0000000140396F75    mysqld.exe!btr_pcur_restore_position()[btr0pcur.c:217]
0000000140338587    mysqld.exe!row_unlock_for_mysql()[row0mysql.c:1544]
000000014032AD35    mysqld.exe!ha_innobase::unlock_row()[ha_innodb.cc:4145]
00000001401C3CEC    mysqld.exe!evaluate_join_record()[sql_select.cc:11221]
00000001401CB675    mysqld.exe!sub_select()[sql_select.cc:11083]
00000001401C3DA4    mysqld.exe!evaluate_join_record()[sql_select.cc:11196]
00000001401CB675    mysqld.exe!sub_select()[sql_select.cc:11083]
00000001401E448A    mysqld.exe!do_select()[sql_select.cc:10837]
00000001401E586B    mysqld.exe!JOIN::exec()[sql_select.cc:2196]
00000001401E605A    mysqld.exe!mysql_select()[sql_select.cc:2376]
00000001401A18DA    mysqld.exe!mysql_execute_command()[sql_parse.cc:3263]
00000001401A55A6    mysqld.exe!mysql_parse()[sql_parse.cc:5813]
00000001401A62DA    mysqld.exe!dispatch_command()[sql_parse.cc:1218]
00000001401A73A7    mysqld.exe!do_command()[sql_parse.cc:857]
0000000140248EC7    mysqld.exe!handle_one_connection()[sql_connect.cc:1115]
00000001402BAEB5    mysqld.exe!pthread_start()[my_winthread.c:85]
00000001403CE7D7    mysqld.exe!_callthreadstart()[thread.c:295]
00000001403CE8A5    mysqld.exe!_threadstart()[thread.c:275]
0000000077D6B69A    kernel32.dll!BaseThreadStart()
[25 Feb 2009 22:53] Shane Bester
I've put a simpler testcase on bug #39320 . Let's use that one instead, since this one is already closed.
[5 May 2010 15:04] 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 1:44] 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 15:07] Paul Dubois
Push resulted from incorporation of InnoDB tree. No changes pertinent to this bug.
Re-closing.
[17 Jun 2010 12:19] 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:06] 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:47] 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)