From 435df1859fc503c884cdec9eaceb7f5f102af70d Mon Sep 17 00:00:00 2001 From: unknown Date: Wed, 4 Jul 2007 21:55:26 +0200 Subject: Bug#26827 - table->read_set is set incorrectly, causing update of a different column For efficiency some storage engines do not read a complete record for update, but only the columns required for selecting the rows. When updating a row of a partitioned table, modifying a column that is part of the partition or subpartition expression, then the row may need to move from one [sub]partition to another one. This is done by inserting the new row into the target [sub]partition and deleting the old row from the originating one. For the insert we need a complete record. If an above mentioned engine was used for a partitioned table, we did not have a complete record in update_row(). The implicitly executed write_row() got an incomplete record. This is solved by instructing the engine to read a complete record if one of the columns of the partition or subpartiton is to be updated. No testcase. This can be reproduced with Falcon only. The engines contained in standard 5.1 do always return complete records on update. sql/ha_partition.cc: Bug#26827 - table->read_set is set incorrectly, causing update of a different column Setting partition field bits in read_set if a writing operation is going on. This replaces the old function include_partition_fields_in_used_fields(). Setting all bits in read_set if write_set contains a column used in a partition or subpartition expression. Removed include_partition_fields_in_used_fields(). sql/ha_partition.h: Bug#26827 - table->read_set is set incorrectly, causing update of a different column Removed declaration of include_partition_fields_in_used_fields(). sql/partition_info.h: Bug#26827 - table->read_set is set incorrectly, causing update of a different column Added a bitmap to partition_info for a quick check of columns used in a partition or subpartition expression. sql/sql_partition.cc: Bug#26827 - table->read_set is set incorrectly, causing update of a different column Initializing the new bitmap with all columns used in a partition or subpartition expression. --- sql/sql_partition.cc | 35 +++++++++++++++++++++++++++++++++-- 1 file changed, 33 insertions(+), 2 deletions(-) (limited to 'sql/sql_partition.cc') diff --git a/sql/sql_partition.cc b/sql/sql_partition.cc index ad3cf2d3e7a..a44af968d9f 100644 --- a/sql/sql_partition.cc +++ b/sql/sql_partition.cc @@ -523,6 +523,7 @@ static bool set_up_field_array(TABLE *table, SYNOPSIS create_full_part_field_array() + thd Thread handle table TABLE object for which partition fields are set-up part_info Reference to partitioning data structure @@ -537,11 +538,12 @@ static bool set_up_field_array(TABLE *table, This function is called from fix_partition_func */ -static bool create_full_part_field_array(TABLE *table, +static bool create_full_part_field_array(THD *thd, TABLE *table, partition_info *part_info) { bool result= FALSE; Field **ptr; + my_bitmap_map *bitmap_buf; DBUG_ENTER("create_full_part_field_array"); if (!part_info->is_sub_partitioned()) @@ -578,6 +580,35 @@ static bool create_full_part_field_array(TABLE *table, part_info->full_part_field_array= field_array; part_info->no_full_part_fields= no_part_fields; } + + /* + Initialize the set of all fields used in partition and subpartition + expression. Required for testing of partition fields in write_set + when updating. We need to set all bits in read_set because the row + may need to be inserted in a different [sub]partition. + */ + if (!(bitmap_buf= (my_bitmap_map*) + thd->alloc(bitmap_buffer_size(table->s->fields)))) + { + mem_alloc_error(bitmap_buffer_size(table->s->fields)); + result= TRUE; + goto end; + } + if (bitmap_init(&part_info->full_part_field_set, bitmap_buf, + table->s->fields, FALSE)) + { + mem_alloc_error(table->s->fields); + result= TRUE; + goto end; + } + /* + full_part_field_array may be NULL if storage engine supports native + partitioning. + */ + if ((ptr= part_info->full_part_field_array)) + while (*ptr) + bitmap_set_bit(&part_info->full_part_field_set, (*ptr++)->field_index); + end: DBUG_RETURN(result); } @@ -1636,7 +1667,7 @@ bool fix_partition_func(THD *thd, TABLE *table, my_error(ER_PARTITION_FUNCTION_IS_NOT_ALLOWED, MYF(0)); goto end; } - if (unlikely(create_full_part_field_array(table, part_info))) + if (unlikely(create_full_part_field_array(thd, table, part_info))) goto end; if (unlikely(check_primary_key(table))) goto end; -- cgit v1.2.1 From 26af0b96a8d7edb8987ff604f415b3814ee47ece Mon Sep 17 00:00:00 2001 From: unknown Date: Thu, 5 Jul 2007 11:31:03 +0200 Subject: Bug#26827 - table->read_set is set incorrectly, causing update of a different column Post-pushbuild fix. bitmap_set_bit() is an inline function in DEBUG builds and a macro in non-DEBUG builds. The latter evaluates its 'bit' argument twice. So one must not use increment/decrement operators on this argument. Moved increment of pointer out of bitmap_set_bit() call. include/my_bitmap.h: Bug#26827 - table->read_set is set incorrectly, causing update of a different column Added a warning comment. sql/sql_partition.cc: Bug#26827 - table->read_set is set incorrectly, causing update of a different column Moved increment of pointer out of bitmap_set_bit() call. --- sql/sql_partition.cc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'sql/sql_partition.cc') diff --git a/sql/sql_partition.cc b/sql/sql_partition.cc index a44af968d9f..191859e0ed4 100644 --- a/sql/sql_partition.cc +++ b/sql/sql_partition.cc @@ -606,8 +606,8 @@ static bool create_full_part_field_array(THD *thd, TABLE *table, partitioning. */ if ((ptr= part_info->full_part_field_array)) - while (*ptr) - bitmap_set_bit(&part_info->full_part_field_set, (*ptr++)->field_index); + for (; *ptr; ptr++) + bitmap_set_bit(&part_info->full_part_field_set, (*ptr)->field_index); end: DBUG_RETURN(result); -- cgit v1.2.1