mirror/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2026-05-09 16:44:29 +02:00
Code Issues Projects Releases Packages Wiki Activity

ha_innodb.cc:

Browse source 
"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
This commit is contained in:
unknown 2005-01-13 21:58:47 +02:00
commit 68075175d6
1 changed files with 6 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

7
sql/ha_innodb.cc
View file

@ -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;