Bug #7804 InnoDB: support varying page sizes
Submitted: 11 Jan 2005 15:03 Modified: 8 Jan 2014 14:48
Reporter: Shawn Hartsock Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server: InnoDB storage engine Severity:S4 (Feature request)
Version:4.1.7-log OS:Any (GNU/Linux 2.6.9 SMP)
Assigned to: Assigned Account CPU Architecture:Any

[11 Jan 2005 15:03] Shawn Hartsock
Description:

During an update of a specific feild in an InnoDB table mysqld fails an assertion and crashes. Tables have been recreated from a text mysqldump. We have had 3 such crashes spread over the 10 days since migrating to 4.1.7-log each crash is associated with an update on a specific feild in a specific table.

After recovery, field inserts and updates work normally. Testing with inserts and updates of assorted sizes works properly. 

Our Innobase code was modified to allow large row inserts as follows:

In the file innobase/include/univ.i:
===========================================================
    #define UNIV_PAGE_SIZE (2 * 8192)
    was changed to
    #define UNIV_PAGE_SIZE (2 * 32768)

    #define UNIV_PAGE_SIZE_SHIFT 14
    was changed to
    #define UNIV_PAGE_SIZE_SHIFT 16
===========================================================

errorlog:
===========================================================
050110 10:56:02InnoDB: Assertion failure in thread 10698772 in file btr0cur.c line 2844
InnoDB: Failing assertion: local_len >= BTR_EXTERN_FIELD_REF_SIZE
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/mysql/en/Forcing_recovery.html
InnoDB: about forcing recovery.
mysqld got signal 11;
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=67108864
read_buffer_size=2093056
max_used_connections=185
max_connections=200
threads_connected=26
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 2112734 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x46d5c7a8
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...
Cannot determine thread, fp=0xbd3fe4d8, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x814ed5a
0xb7f77be5
0x8286c0f
0x828293d
0x827e6bb
0x825ef18
0x825e259
0x825d78d
0x825caca
0x8247fff
0x81d651f
0x81a4073
0x816260f
0x8166a16
0x8160952
0x816050b
0x815fd29
0xb7f71cc4
0xb7df5037
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do 
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x9bbcc28 = UPDATE AppData

             SET TotalTeaching = '15',
                 NonTeachingExp = 'Long Text feild's contents TEXT OMITTED for privacy
thd->thread_id=5201
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.

Number of processes running now: 0
===========================================================

Resolve Stack returns:
===========================================================
0x814ed5a handle_segfault + 570
0xb7f77be5 _end + -1347232751
0x8286c0f btr_rec_copy_externally_stored_field + 7807
0x828293d btr_cur_mark_dtuple_inherited_extern + 237
0x827e6bb btr_cur_optimistic_update + 1579
0x825ef18 row_upd_in_place_in_select + 7848
0x825e259 row_upd_in_place_in_select + 4585
0x825d78d row_upd_in_place_in_select + 1821
0x825caca row_upd_step + 298
0x8247fff row_update_for_mysql + 479
0x81d651f _ZN11ha_innobase10update_rowEPKcPc + 207
0x81a4073 _Z12mysql_updateP3THDP13st_table_listR4ListI4ItemES6_PS4_jP8st_orderm15enum_duplicates + 2339
0x816260f _Z21mysql_execute_commandP3THD + 3279
0x8166a16 _Z11mysql_parseP3THDPcj + 198
0x8160952 _Z16dispatch_command19enum_server_commandP3THDPcj + 1010
0x816050b _Z10do_commandP3THD + 123
0x815fd29 handle_one_connection + 841
0xb7f71cc4 _end + -1347257104
0xb7df5037 _end + -1348816797
===========================================================

How to repeat:
We cannot yet reproduce the bug although it appears to happen regularly.

Suggested fix:
None.
The server must be restarted and all servers using replication must be restarted aswell.
[11 Jan 2005 15:29] Marko Mäkelä
Other InnoDB page sizes than 16 kilobytes are not supported. If you can provide a reproducible test case, I can have a look at it. You might get more assertion failures by defining UNIV_DEBUG and possibly other debug symbols in innobase/include/univ.i.
[12 Feb 2005 13:42] Heikki Tuuri
Hi!

We will test and debug possible problems in 32 kB and 64 kB pages when increasing the default 16 kB page size becomes actual.

Regards,

Heikki
[8 Jan 2014 14:48] Erlend Dahl
This has been partially solved in MySQL 5.6. InnoDB now supports 4K, 8K and 16K page sizes.

Moving to 'verified' since we are discontinuing the use of 'to be fixed later'.