mirror of
https://github.com/MariaDB/server.git
synced 2025-01-31 11:01:52 +01:00
d076be2a32
HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK". Attempt to update an InnoDB temporary table under LOCK TABLES led to assertion failure in both debug and production builds if this temporary table was explicitly locked for READ. The same scenario works fine for MyISAM temporary tables. The assertion failure was caused by discrepancy between lock that was requested on the rows of temporary table at LOCK TABLES time and by update operation. Since SQL-layer requested a read-lock at LOCK TABLES time InnoDB engine assumed that upcoming statements which are going to be executed under LOCK TABLES will only read table and therefore should acquire only S-lock. An update operation broken this assumption by requesting X-lock. Possible approaches to fixing this problem are: 1) Skip locking of temporary tables as locking doesn't make any sense for connection-local objects. 2) Prohibit changing of temporary table locked by LOCK TABLES ... READ. Unfortunately both of these approaches have drawbacks which make them unviable for stable versions of server. So this patch takes another approach and changes code in such way that LOCK TABLES for a temporary table will always request write lock. In 5.1 version of this patch switch from read lock to write lock is done inside of InnoDBs handler methods as doing it on SQL-layer causes compatibility troubles with FLUSH TABLES WITH READ LOCK. |
||
|---|---|---|
| .. | ||
| binlog | ||
| engines | ||
| federated | ||
| funcs_1 | ||
| funcs_2 | ||
| im | ||
| innodb | ||
| innodb_plugin | ||
| jp | ||
| large_tests | ||
| manual | ||
| ndb | ||
| ndb_team | ||
| parts | ||
| rpl | ||
| rpl_ndb | ||
| stress | ||
| sys_vars | ||