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.

1 files changed, 7 insertions, 0 deletions

diff --git a/sql/partition_info.h b/sql/partition_info.h
index ce2f2a7b358..10edea074c0 100644
--- a/sql/partition_info.h
+++ b/sql/partition_info.h
@@ -81,6 +81,13 @@ public:
   */
   Field **full_part_field_array;
   Field **full_part_charset_field_array;
+  /*
+    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.
+  */
+  MY_BITMAP full_part_field_set;
 
   /*
     When we have a field that requires transformation before calling the