Bug #42147 Concurrent DML and LOCK TABLE ... READ for InnoDB
table cause warnings in errlog
Concurrent execution of LOCK TABLES ... READ statement and DML statements
affecting the same InnoDB table on debug builds of MySQL server might lead
to "Found lock of type 6 that is write and read locked" warnings appearing
in error log.
The problem is that the table-level locking code allows a thread to acquire
TL_READ_NO_INSERT lock on a table even if there is another thread which holds
TL_WRITE_ALLOW_WRITE lock on the same table. At the same time, the locking
code assumes that that such locks are incompatible (for example, see check_locks()).
This doesn't lead to any problems other than warnings in error log for
debug builds of server since for InnoDB tables TL_READ_NO_INSERT type of
lock is only used for LOCK TABLES and for this statement InnoDB also
performs its own table-level locking.
Unfortunately, the table lock compatibility matrix cannot be updated to disallow
TL_READ_NO_INSERT when another thread holds TL_WRITE_ALLOW_WRITE without
causing starvation of LOCK TABLE READ in InnoDB under high write load.
This patch therefore contains no code changes.
The issue will be fixed later when LOCK TABLE READ has been updated
to not use table locks. This bug will therefore be marked as
"To be fixed later".
Code comment in thr_lock.c expanded to clarify the issue and a
test case based on the bug description added to innodb_mysql_lock.test.
Note that a global suppression rule has been added to both MTR v1 and v2
for the "Found lock of type 6 that is write and read locked" warning.
These suppression rules must be removed once this bug is properly fixed.
Text conflict in mysql-test/collections/default.experimental
Text conflict in mysql-test/r/show_check.result
Text conflict in mysql-test/r/sp-code.result
Text conflict in mysql-test/suite/binlog/r/binlog_tmp_table.result
Text conflict in mysql-test/suite/rpl/t/disabled.def
Text conflict in mysql-test/t/show_check.test
Text conflict in mysys/my_delete.c
Text conflict in sql/item.h
Text conflict in sql/item_cmpfunc.h
Text conflict in sql/log.cc
Text conflict in sql/mysqld.cc
Text conflict in sql/repl_failsafe.cc
Text conflict in sql/slave.cc
Text conflict in sql/sql_parse.cc
Text conflict in sql/sql_table.cc
Text conflict in sql/sql_yacc.yy
Text conflict in storage/myisam/ha_myisam.cc
Corrected results for
stm_auto_increment_bug33029.reject 2009-12-01
20:01:49.000000000 +0300
<andrei> @@ -42,9 +42,6 @@
<andrei> RETURN i;
<andrei> END//
<andrei> CALL p1();
<andrei> -Warnings:
<andrei> -Note 1592 Statement may not be safe to log in statement
format.
<andrei> -Note 1592 Statement may not be safe to log in statement
format.
There should be indeed no Note present because there is in fact autoincrement
top-level query in sp() that triggers inserting in yet another auto-inc table.
(todo: alert DaoGang to improve the test).
Post-push fix: Removed MTRv1 arguments according to the
original patch. Although there is a version check, the patch
was pushed to a 5.1 GA staging tree, while the version check
considers version 5.2. This makes the deprecated parameters
to be used, despite the fact that they are not valid anymore.
Part of MTRv1 is currently used in RQG semisync test, and this
was causing the test to fail on slave startup.
It should be safe to uncomment when merging up to celosia.
- disabled main.innodb_bug47777.test with InnoDB plugin
until fix for plugin is applied.
- disabled main.innodb-autoinc.test (failing)
- re-enabled main.innodb_bug39438.test
- added error message suppression to innodb_bug39438, as
requested by InnoDB/Oracle
- reverted change to main.innodb_bug34300 as plugin specific.
The reason for the bug is that mysqtest as well as other client tools
running in test suite (mysqlbinlog, mysqldump) will first try to connect
whatever database has created shared memory with default base name
"MySQL" and use this. (Same effect could be seen on Unix if mtr would
not care to calculate "port" and "socket" parameter).
The fix ensures that all client tools and running in mtr use unique
per-database shared memory base parameters, so there is no possibility
to clash with already installed one. We use socket name for shared memory
base (it's known to be unique). This shared-memory-base is written to the
MTR config file to the [client] and [mysqld] sections. Fix made also made
sure all client tools understand and correctly handle --shared-memory-base.
Prior to this patch it was not the case for mysqltest, mysqlbinlog and
mysql_client_test.
All new connections done from mtr scripts via connect() will by default
set shared-memory-base. And finally, there is a possibility to force
shared memory or pipe connection and overwrite shared memory/pipe base name
from within mtr scripts via optional PIPE or SHM modifier. This functionality
was manually backported from 6.0
(original patch http://lists.mysql.com/commits/74749)
Knowledge of no SSL support is not used
Skip tests the same way e.g. innodb tests are
Does not refer to have_ssl_communication.inc,
will add this when merging to 6.0-codebase
1. BUG#46000 - using index called GEN_CLUST_INDEX crashes server
Detailed revision comments:
r5895 | jyang | 2009-09-15 03:39:21 +0300 (Tue, 15 Sep 2009) | 5 lines
branches/5.1: Disallow creating index with the name of
"GEN_CLUST_INDEX" which is reserved for the default system
primary index. (Bug #46000) rb://149 approved by Marko Makela.
The problem is that safe_kill_win fails to detect a dead process. OpenProcess() will
succeed even after the process died, it will first fail after the last handle to process
is closed.
To fix the problem, check process status with GetExitCodeProcess() and consider
process to be dead if the exit code returned by this routine is not STILL_ALIVE.
value from the index (PRIMARY)
With the fix for BUG#46760, we correctly flag the presence of row_type
only when it's actually changed and enables the FAST ALTER TABLE which was
disabled with the BUG#39200.
So the changes made by BUG#46760 makes MySQL data dictionaries to be out of
sync but they are handled already by InnoDB with this BUG#44030.
The test was originally written to handle this but we requested Innodb to
update the test as the data dictionaries were in sync after the fix for
BUG#39200.
Adjusting the innodb-autoinc testcase as mentioned in the comments.
