Comment 12 for bug 1280896

This (with latest revision merged) crashes as:

granted: (26 seqno -1 wsrep (0, 1, 1) cmd 3 6 INSERT INTO e SELECT * FROM `table500_innodb_bigint_autoinc`)
2014-06-09 22:52:47 13680 [Note] WSREP: MDL ticket: type: shared write space: TABLE db: test name: e
2014-06-09 22:52:47 13680 [Note] WSREP: wsrep_abort_thd, by: 140059626616576, victim: 140059891640064
2014-06-09 22:52:47 13680 [Note] WSREP: abort transaction: BF: ALTER TABLE e RENAME `table1000_innodb_int` victim: INSERT INTO e SELECT * FROM `table500_innodb_bigint_autoinc`
2014-06-09 22:52:47 13680 [Note] WSREP: cluster conflict due to high priority abort for threads:
2014-06-09 22:52:47 13680 [Note] WSREP: Winning thread:
   THD: 44, mode: total order, state: executing, conflict: no conflict, seqno: 365
   SQL: ALTER TABLE e RENAME `table1000_innodb_int`
2014-06-09 22:52:47 13680 [Note] WSREP: Victim thread:
   THD: 26, mode: local, state: executing, conflict: must abort, seqno: -1
   SQL: INSERT INTO e SELECT * FROM `table500_innodb_bigint_autoinc`
2014-06-09 22:52:47 13680 [Note] WSREP: BF kill (1, seqno: 365), victim: (26) trx: 2773
2014-06-09 22:52:47 13680 [Note] WSREP: Aborting query: INSERT INTO e SELECT * FROM `table500_innodb_bigint_autoinc`
2014-06-09 22:52:47 13680 [Note] WSREP: victim 2773 in MUST ABORT state
2014-06-09 22:52:47 13680 [Note] WSREP: MDL victim killed at add_ticket
2014-06-09 22:52:47 13680 [Note] WSREP: TO BEGIN: -1, 0 : DROP TABLE IF EXISTS l
2014-06-09 22:52:48 13680 [Note] WSREP: client rollback due to BF abort for (26), query: INSERT INTO e SELECT * FROM `table500_innodb_bigint_autoinc`
2014-06-09 22:52:48 13680 [Note] WSREP: abort in exec query state, avoiding autocommit
2014-06-09 22:52:48 13680 [Note] WSREP: wsrep retrying AC query: INSERT INTO e SELECT * FROM `table500_innodb_bigint_autoinc`
2014-06-09 22:52:48 13680 [Note] WSREP: MDL conflict db=test table=e ticket=8 solved by abort
2014-06-09 22:52:48 7f622c4ab700 InnoDB: Assertion failure in thread 140059626616576 in file lock0lock.cc line 2311
InnoDB: Failing assertion: !(type_mode & 1024)
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.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.

The assertion hits here:

 type_mode |= LOCK_REC;

 /* If rec is the supremum record, then we can reset the gap bit, as
 all locks on the supremum are automatically of the gap type, and we
 try to avoid unnecessary memory consumption of a new record lock
 struct for a gap type lock */

 if (UNIV_UNLIKELY(heap_no == PAGE_HEAP_NO_SUPREMUM)) {
  ut_ad(!(type_mode & LOCK_REC_NOT_GAP));

  /* There should never be LOCK_REC_NOT_GAP on a supremum
  record, but let us play safe */

  type_mode = type_mode & ~(LOCK_GAP | LOCK_REC_NOT_GAP);
 }