From 68075175d6841cded6e2544bccf36f4ccab47a6e Mon Sep 17 00:00:00 2001 From: unknown Date: Thu, 13 Jan 2005 21:58:47 +0200 Subject: [PATCH] ha_innodb.cc: "Add a comment why data modifying SQL statements MUST always use a locking read in tables that they read: otherwise the execution is not serializable, and in many cases is not well-defined; we also merged the associated bug fix from 4.1" sql/ha_innodb.cc: Add a comment why data modifying SQL statements MUST always use a locking read in tables that they read: otherwise the exxecution is not serializable, and in many cases is not well-defined; 5 minutes ago we merged the associated bug fix from 4.0 and 4.1 --- sql/ha_innodb.cc | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/sql/ha_innodb.cc b/sql/ha_innodb.cc index 068d498a11d..d49f1c1ad46 100644 --- a/sql/ha_innodb.cc +++ b/sql/ha_innodb.cc @@ -5717,7 +5717,12 @@ ha_innobase::store_lock( MySQL is doing LOCK TABLES ... READ. 5) we let InnoDB do locking reads for all SQL statements that are not simple SELECTs; note that select_lock_type in this - case may get strengthened in ::external_lock() to LOCK_X. */ + case may get strengthened in ::external_lock() to LOCK_X. + Note that we MUST use a locking read in all data modifying + SQL statements, because otherwise the execution would not be + serializable, and also the results from the update could be + unexpected if an obsolete consistent read view would be + used. */ prebuilt->select_lock_type = LOCK_S; prebuilt->stored_select_lock_type = LOCK_S;