Commit ecd22993 authored by tsmith@siva.hindu.god's avatar tsmith@siva.hindu.god

Bug #26642: create index corrupts table definition in .frm

Thanks to Martin Friebe for finding and submitting a fix for this bug!

A table with maximum number of key segments and maximum length key name
would have a corrupted .frm file, due to an incorrect calculation of the
complete key length.  Now the key length is computed correctly (I hope) :-)

MyISAM would reject a table with the maximum number of keys and the maximum
number of key segments in all keys.  It would allow one less than this total
maximum.  Now MyISAM accepts a table defined with the maximum.  (This is a
very minor issue.)
parent ebe44e6e
......@@ -219,7 +219,7 @@ MI_INFO *mi_open(const char *name, int mode, uint open_flags)
key_parts+=fulltext_keys*FT_SEGS;
if (share->base.max_key_length > MI_MAX_KEY_BUFF || keys > MI_MAX_KEY ||
key_parts >= MI_MAX_KEY * MI_MAX_KEY_SEG)
key_parts > MI_MAX_KEY * MI_MAX_KEY_SEG)
{
DBUG_PRINT("error",("Wrong key info: Max_key_length: %d keys: %d key_parts: %d", share->base.max_key_length, keys, key_parts));
my_errno=HA_ERR_UNSUPPORTED;
......
This diff is collapsed.
This diff is collapsed.
......@@ -1283,7 +1283,18 @@ File create_frm(register my_string name, const char *db, const char *table,
fileinfo[3]= (uchar) ha_checktype(create_info->db_type);
fileinfo[4]=1;
int2store(fileinfo+6,IO_SIZE); /* Next block starts here */
key_length=keys*(7+NAME_LEN+MAX_REF_PARTS*9)+16;
/*
For each key (see unireg.cc::pack_keys()):
8 bytes for the key header
9 bytes for each key-part (MAX_REF_PARTS)
NAME_LEN bytes for the name
1 byte for the NAMES_SEP_CHAR (before the name)
For all keys:
6 bytes for the header
1 byte for the NAMES_SEP_CHAR (after the last name)
9 extra bytes (padding for safety? alignment?)
*/
key_length= keys * (8 + MAX_REF_PARTS * 9 + NAME_LEN + 1) + 16;
length=(ulong) next_io_size((ulong) (IO_SIZE+key_length+reclength));
int4store(fileinfo+10,length);
if (key_length > 0xffff) key_length=0xffff;
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment