LP #1157037: create_duplicate_weedout_tmp_table() leaves key_part_flag uninitialized

**Reported in Launchpad by Alexey Kopytov last update 07-11-2014 14:39:02

create_duplicate_weedout_tmp_table() leaves the key_part_flag field of key_part_info uninitialized when building a key definition for the temporary table. Under some circumstances it may also use that uninitialized value when adding the HA_END_SPACE_ARE_EQUAL flag:

{
key_part_info->null_bit=0;
key_part_info->field= field;
key_part_info->offset= field->offset(table->record[0]);
key_part_info->length= (uint16) field->key_length();
key_part_info->type= (uint8) field->key_type();
key_part_info->key_type = FIELDFLAG_BINARY;
if (!using_unique_constraint)

{ key_field= field->new_key_field(thd->mem_root, table, group_buff); if (!key_field) goto err; key_part_info->key_part_flag|= HA_END_SPACE_ARE_EQUAL; //todo need this? }

keyinfo->key_length+= key_part_info->length;
}

The table being created may be either HEAP or MyISAM. The key_part_flag field is not used by the HEAP engine in MySQL (though it is used in Percona Server), but it is used by MyISAM in all branches.

For comparison, create_tmp_table() always initializes that field by calling KEY_PART_INFO::init_from_field().

It may take me a while to build a test case for MySQL that would fail (or indicate uninitialized value usage under Valgrind). However, the problem should be clear from code analysis and comparison with create_tmp_table().