Bug #29567 ha_tina doesn't have HA_PARTIAL_COLUMN_READ flag

• Submitted: 5 Jul 2007 8:19
• Modified: 23 Oct 2007 17:16
• Reporter: Sergei Golubchik
• Status: Closed
• Category: MySQL Server: CSV
• Severity: S3 (Non-critical)
• OS: Any
• Assigned to: Ingo Strüwing
• CPU Architecture: Any

[5 Jul 2007 8:19] Sergei Golubchik

Description:
ha_tina only returns requested columns in the record buffer (it respects read_set bitmap), but doesn't have HA_PARTIAL_COLUMN_READ table_flag. Without this flag MySQL thinks that all columns in the record buffer are returned.
This could cause "bad data" bug in, for example, UPDATE if read_set doesn't include all columns, MySQL will believe it does and will try to check whether a row was changed or not - which may produce false negatives.

How to repeat:
.

[19 Oct 2007 17:06] Ingo Strüwing

Please help finding a test case. I tried this one, but it works:

+CREATE TABLE t1 (c1 INT, c2 INT, c3 INT) ENGINE=CSV;
+INSERT INTO t1 VALUES (1,1,1), (1,2,2), (2,1,3), (2,2,4);
+UPDATE t1 SET c2=3 WHERE c1=1;
+SELECT * FROM t1;
+c1     c2      c3
+1      3       1
+1      3       2
+2      1       3
+2      2       4
+DROP TABLE t1;

[23 Oct 2007 17:16] Sergei Golubchik

Ok, it's safe indeed, after a fix for BUG#28971.

ha_tina now has the following code:

  /* We must read all columns in case a table is opened for update */
  read_all= !bitmap_is_clear_all(table->write_set);

so in the only case when HA_PARTIAL_COLUMN_READ could cause a problem (update) ha_tina behaves as if it could not read a part of the row, and fills the row buffer completely.