Percona Server with XtraDB

create_duplicate_weedout_tmp_table() leaves key_part_flag uninitialized

Reported by Alexey Kopytov on 2013-03-19
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MySQL Server
Unknown
Unknown
Percona Server
Status tracked in 5.6
5.1
Undecided
Unassigned
5.5
Undecided
Unassigned
5.6
High
Laurynas Biveinis

Bug Description

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().

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.