is allowed on views (not documented, broken)".
Remove support of ALTER TABLE RENAME for views as:
a) this feature was not documented,
c) does not add any compatibility with other databases,
b) its implementation doesn't follow metadata locking
protocol by accessing .FRM without holding any
metadata lock,
c) its implementation complicates ALTER TABLE's code
by introducing yet another separate branch to it.
After this patch one can rename a view by using the
documented way - RENAME TABLE statement.
mysql-test/r/rename.result:
Adjusted existing test case for bug #14959 "ALTER TABLE isn't
able to rename a view" after fixing bug #53976: "ALTER TABLE
RENAME is allowed on views (not documented, broken)".
mysql-test/r/view.result:
Adjusted test case after removing support for renaming
of views through ALTER TABLE ... RENAME.
mysql-test/t/rename.test:
Adjusted existing test case for bug #14959 "ALTER TABLE isn't
able to rename a view" after fixing bug #53976: "ALTER TABLE
RENAME is allowed on views (not documented, broken)".
mysql-test/t/view.test:
Adjusted test case after removing support for renaming
of views through ALTER TABLE ... RENAME.
sql/sql_table.cc:
Removed support for ALTER TABLE ... RENAME for views.
This feature was not properly documented and its
implementation was not following metadata locking
protocol.
Post-merge fix: Retrieve handler statistics to workaround quirks
of the archive storage engine.
mysql-test/t/archive.test:
Add test case.
sql/sql_truncate.cc:
Call info method with has side-effects related to the archive
storage engine. It will cause rows to become visible, allowing
a error to be thrown once we attempt to delete the rows.
The problem was that mdl_sync.test was failing sporadically,
due to fact that part of the test didn't take into account
effects of MyISAM's concurrent insert.
This patch solves the problem by making test case robust
against concurrent insert.
SELECT and ALTER TABLE ... REBUILD PARTITION".
ALTER TABLE on InnoDB table (including partitioned tables)
acquired exclusive locks on rows of table being altered.
In cases when there was concurrent transaction which did
locking reads from this table this sometimes led to a
deadlock which was not detected by MDL subsystem nor by
InnoDB engine (and was reported only after exceeding
innodb_lock_wait_timeout).
This problem stemmed from the fact that ALTER TABLE acquired
TL_WRITE_ALLOW_READ lock on table being altered. This lock
was interpreted as a write lock and thus for table being
altered handler::external_lock() method was called with
F_WRLCK as an argument. As result InnoDB engine treated
ALTER TABLE as an operation which is going to change data
and acquired LOCK_X locks on rows being read from old
version of table.
In case when there was a transaction which already acquired
SR metadata lock on table and some LOCK_S locks on its rows
(e.g. by using it in subquery of DML statement) concurrent
ALTER TABLE was blocked at the moment when it tried to
acquire LOCK_X lock before reading one of these rows.
The transaction's attempt to acquire SW metadata lock on
table being altered led to deadlock, since it had to wait
for ALTER TABLE to release SNW lock. This deadlock was not
detected and got resolved only after timeout expiring
because waiting were happening in two different subsystems.
Similar deadlocks could have occured in other situations.
This patch tries to solve the problem by changing ALTER TABLE
implementation to use TL_READ_NO_INSERT lock instead of
TL_WRITE_ALLOW_READ. After this step handler::external_lock()
is called with F_RDLCK as an argument and InnoDB engine
correctly interprets ALTER TABLE as operation which only
reads data from original version of table. Thanks to this
ALTER TABLE acquires only LOCK_S locks on rows it reads.
This, in its turn, causes inter-subsystem deadlocks to go
away, as all potential lock conflicts and thus deadlocks will
be limited to metadata locking subsystem:
- When ALTER TABLE reads rows from table being altered it
can't encounter any locks which conflict with LOCK_S row
locks. There should be no concurrent transactions holding
LOCK_X row locks. Such a transaction should have been
acquired SW metadata lock on table first which would have
conflicted with ALTER's SNW lock.
- Vice versa, when DML which runs concurrently with ALTER
TABLE tries to lock row it should be requesting only LOCK_S
lock which is compatible with locks acquired by ALTER,
as otherwise such DML must own an SW metadata lock on table
which would be incompatible with ALTER's SNW lock.
mysql-test/r/innodb_mysql_lock2.result:
Added test for bug #51263 "Deadlock between transactional
SELECT and ALTER TABLE ... REBUILD PARTITION".
mysql-test/suite/rpl_ndb/r/rpl_ndb_binlog_format_errors.result:
Since CREATE TRIGGER no longer acquires write lock on table
it is no longer interpreted as an operation which modifies
table data and therefore no longer fails if invoked for
SBR-only engine in ROW mode.
mysql-test/suite/rpl_ndb/t/rpl_ndb_binlog_format_errors.test:
Since CREATE TRIGGER no longer acquires write lock on table
it is no longer interpreted as an operation which modifies
table data and therefore no longer fails if invoked for
SBR-only engine in ROW mode.
mysql-test/t/innodb_mysql_lock2.test:
Added test for bug #51263 "Deadlock between transactional
SELECT and ALTER TABLE ... REBUILD PARTITION".
sql/ha_partition.cc:
When ALTER TABLE creates a new partition to be filled from
other partition lock it in F_WRLCK mode instead of using
mode which was used for locking the whole table (it is
F_RDLCK now).
sql/lock.cc:
Replaced conditions which used TL_WRITE_ALLOW_READ
lock type with equivalent conditions using
TL_WRITE_ALLOW_WRITE. This should allow to get rid
of TL_WRITE_ALLOW_READ lock type eventually.
sql/mdl.cc:
Updated outdated comment to reflect current situation.
sql/sql_base.cc:
Replaced conditions which used TL_WRITE_ALLOW_READ
lock type with equivalent conditions using
TL_WRITE_ALLOW_WRITE. This should allow to get rid
of TL_WRITE_ALLOW_READ lock type eventually.
sql/sql_table.cc:
mysql_admin_table():
Use TL_WRITE_ALLOW_WRITE lock type instead of
TL_WRITE_ALLOW_READ to determine that we need to acquire
upgradable metadata lock. This should allow to completely
get rid of TL_WRITE_ALLOW_READ in long term.
mysql_recreate_table():
ALTER TABLE now requires TL_READ_NO_INSERT thr_lock.c lock
instead of TL_WRITE_ALLOW_READ.
sql/sql_trigger.cc:
Changed CREATE/DROP TRIGGER implementation to use
TL_READ_NO_INSERT lock instead of TL_WRITE_ALLOW_READ lock.
The latter is no longer necessary since:
a) We now can rely on metadata locks to achieve proper
isolation between two DDL statements or DDL and DML
statements.
b) This statement does not change any data in table so there
is no need to inform storage engine about it.
sql/sql_yacc.yy:
Changed implementation of ALTER TABLE (and CREATE/DROP INDEX
as a consequence) to use TL_READ_NO_INSERT lock instead of
TL_WRITE_ALLOW_READ lock. This is possible since:
a) We now can rely on metadata locks to achieve proper
isolation between two DDL statements or DDL and DML
statements.
b) This statement only reads data in table being open.
We write data only to the new version of table and
then replace with it old version of table under
X metadata lock.
Thanks to this change InnoDB will no longer acquire LOCK_X
locks on rows being read by ALTER TABLE (instead LOCK_S
locks will be acquired) and thus cause of bug #51263
"Deadlock between transactional SELECT and ALTER TABLE ...
REBUILD PARTITION" is removed.
Did the similar change for CREATE TRIGGER (see comments
for sql_trigger.cc for details).
The problem was that TRUNCATE TABLE didn't take a exclusive
lock on a table if it resorted to truncating via delete of
all rows in the table. Specifically for InnoDB tables, this
could break proper isolation as InnoDB ends up aborting some
granted locks when truncating a table.
The solution is to take a exclusive metadata lock before
TRUNCATE TABLE can proceed. This guarantees that no other
transaction is using the table.
Incompatible change: Truncate via delete no longer fails
if sql_safe_updates is activated (this was a undocumented
side effect).
libmysqld/CMakeLists.txt:
Add new files to the build list.
libmysqld/Makefile.am:
Add new files to the build list.
mysql-test/extra/binlog_tests/binlog_truncate.test:
Add test case for Bug#42643
mysql-test/include/mix1.inc:
Update test case as TRUNCATE TABLE now grabs a exclusive lock.
Ensure that TRUNCATE waits for granted locks on the table.
mysql-test/suite/binlog/t/binlog_truncate_innodb.test:
As with other data modifying statements, TRUNCATE is still not
possible in a transaction with isolation level READ COMMITTED
or READ UNCOMMITED. It would be possible to implement so, but
it is not worth the effort.
mysql-test/suite/binlog/t/binlog_truncate_myisam.test:
Test under different binlog formats.
mysql-test/suite/binlog/t/disabled.def:
Re-enable test case.
mysql-test/t/innodb_bug38231.test:
Truncate no longer works with row-level locks.
mysql-test/t/mdl_sync.test:
Ensure that a acquired lock is not given up due to a conflict.
mysql-test/t/partition_innodb_semi_consistent.test:
End transaction as to release metadata locks.
mysql-test/t/truncate.test:
A metadata lock is now taken before the object is verified.
sql/CMakeLists.txt:
Add new files to the build list.
sql/Makefile.am:
Add new files to the build list.
sql/datadict.cc:
Introduce a new file specific for data dictionary operations.
sql/datadict.h:
Add header file.
sql/sql_base.cc:
Rename data dictionary function.
sql/sql_bitmap.h:
Include dependency.
sql/sql_delete.cc:
Move away from relying on mysql_delete() to delete all rows of
a table. Thus, move any bits related to truncate to sql_truncate.cc
sql/sql_delete.h:
Remove parameter.
sql/sql_parse.cc:
Add protection against the global read lock -- a intention
exclusive lock can be acquired in the truncate path.
sql/sql_show.cc:
Add sync point for testing scenarios where a pending flush
is ignored.
sql/sql_truncate.cc:
Acquire a shared metadata lock before accessing table metadata.
Upgrade the lock to a exclusive one if the table can be re-created.
Rework binlog rules to better reflect the requirements.
sql/sql_yacc.yy:
Set appropriate lock types for table to be truncated.
sql/table.h:
Move to data dictionary header.
FOR UPDATE is causing a lock".
This patch tries to address problems which were exposed
during backporting of original patch to 5.1 tree.
- It ensures that we don't change locking behavior of simple
SELECT statements on InnoDB tables when they are executed
under LOCK TABLES ... READ and with @@innodb_table_locks=0.
Also we no longer pass TL_READ_DEFAULT/TL_WRITE_DEFAULT
lock types, which are supposed to be parser-only, to
handler::start_stmt() method.
- It makes check_/no_concurrent_insert.inc auxiliary scripts
more robust against changes in test cases that use them
and also ensures that they don't unnecessarily change
environment of caller.
mysql-test/include/check_concurrent_insert.inc:
Reset DEBUG_SYNC facility before and after using it in
auxiliary script. This makes this script more robust against
changes in test cases calling it. It also ensures that script
does not unnecessarily change environment of caller.
mysql-test/include/check_no_concurrent_insert.inc:
Reset DEBUG_SYNC facility before and after using it in
auxiliary script. This makes this script more robust against
changes in test cases calling it. It also ensures that script
does not unnecessarily change environment of caller.
mysql-test/r/innodb-lock.result:
Added coverage for LOCK TABLES ... READ behavior in
@@innodb_table_locks = 0 mode. This test also checks
that an appropriate type of lock is passed to
handler::start_stmt() method.
mysql-test/t/innodb-lock.test:
Added coverage for LOCK TABLES ... READ behavior in
@@innodb_table_locks = 0 mode. This test also checks
that an appropriate type of lock is passed to
handler::start_stmt() method.
sql/sql_base.cc:
Since we no longer set TL_READ as lock type for tables used
in simple SELECT right in the parser, in order to preserve
behavior for such statements on InnoDB tables when in
LOCK TABLES mode with @innodb_table_locks = 0,
check_lock_and_start_stmt() had to be changed to convert
TL_READ_DEFAULT to an appropriate type of read lock before
passing it to handler::start_stmt() method.
We do similar thing for TL_WRITE_DEFAULT as this lock type
is also supposed to be parser-only type.
As consequence read_lock_type_for_table() had to be
adjusted to behave properly when it is called from
check_lock_and_start_stmt() in prelocked mode.
The problem was that OPTMIZE TABLE was allowed to run on a table
in use by a transaction in a different connection. This caused
repeatable read to break.
This bug was fixed by the introduction of metadata locking, WL#4284.
OPTIMIZE TABLE will now be blocked until the transaction using the
table, has ended.
This patch contains a regression test added to innodb_mysql_lock.test
and no code changes.
That was a pure test issue -- filter implementation in Perl did not work
on some platform (the bug occurred on Windows Server 2008 with
Cygwin Perl 5.10.0).
multiquery packet).
Background:
- a query can contain multiple SQL statements;
- the server frees resources allocated to process a query when the
whole query is handled. In other words, resources allocated to process
one SQL statement from a multi-statement query are freed when all SQL
statements are handled.
The problem was that the parser allocated a buffer of size of the whole
query for each SQL statement in a multi-statement query. Thus, if a query
had many SQL-statements (so, the query was long), but each SQL statement
was short, ther parser tried to allocate huge amount of memory (number of
small SQL statements * length of the whole query).
The memory was allocated for a so-called "cpp buffer", which is intended to
store pre-processed SQL statement -- SQL text without version specific
comments.
The fix is to allocate memory for the "cpp buffer" once for all SQL
statements (once for a query).
for ALTER TABLE, LOAD DATA).
ROW_COUNT is now assigned according to the following rules:
- In my_ok():
- for DML statements: to the number of affected rows;
- for DDL statements: to 0.
- In my_eof(): to -1 to indicate that there was a result set.
We derive this semantics from the JDBC specification, where int
java.sql.Statement.getUpdateCount() is defined to (sic) "return the
current result as an update count; if the result is a ResultSet
object or there are no more results, -1 is returned".
- In my_error(): to -1 to be compatible with the MySQL C API and
MySQL ODBC driver.
- For SIGNAL statements: to 0 per WL#2110 specification. Zero is used
since that's the "default" value of ROW_COUNT in the diagnostics area.
sql/protocol.cc:
Fix a typo.
sql/sql_class.h:
- Introduce THD::get_row_count_func() / THD::set_row_count_func();
- Remove the CF_HAS_ROW_COUNT define
sql/sql_parse.cc:
CF_HAS_ROW_COUNT was eliminated.
- Update/fix file layouts for each package type, add new types for
native package formats including deb, rpm and svr4.
- Build all plugins, including debug versions
- Update compiler flags to match current release
- Add missing @VAR@ expansions
- Install correct mysqclient library symlinks
- Fix icc/ia64 builds
- Fix install of libmysqld-debug
- Don't include mysql_embedded
- Remove unpackaged manual pages to avoid missing files warnings
- Don't install mtr's test suite
data is selected or not
Temporary and permanent tables should live in different
namespaces. In this case, resolving a permanent table
name gave the temporary table, resulting in a name
collision.
The bug happened under the following condition:
- there was a user variable of type REAL, containing NULL value
- there was a table with a NOT_NULL column of any type but REAL, having
default value (or auto increment);
- a row was inserted into the table with the user variable as value.
A warning was emitted here.
The problem was that handling of NULL values of REAL type was not properly
implemented: it didn't expect that REAL NULL value can be assigned to other
data type.
Basically, the problem was that set_field_to_null() was used instead of
set_field_to_null_with_conversions().
The fix is to use the right function, or more generally, to allow conversion of
REAL NULL values to other data types.
Problem:
item->name was NULL for Item_user_var_as_out_param
which made strcmp(something, item->name) crash in the LOAD XML code.
Fix:
- item_func.h: Adding set_name() in constuctor for Item_user_var_as_out_param
- sql_load.cc: Changing the condition in write_execute_load_query_log_event() which
distiguished between Item_user_var_as_out_param and Item_field
from
if (item->name == NULL)
to
if (item->type() == Item::FIELD_ITEM)
- loadxml.result, loadxml.test: adding tests
table
If a temporary table A exists, and a (permanent) table
with the same name is attempted created with
"CREATE TABLE ... AS SELECT", the create would fail with
an error.
1050: Table 'A' already exists
The error occured in MySQL 5.1 releases, but is not
present in MySQL 5.5. This patch adds a regression
test to ensure that the problem does not reoccur.
Problem: after introduction of "WL#2649 Number-to-string conversions"
This query:
SET NAMES cp850; -- Or any other non-latin1 ASCII-based character set
SELECT * FROM t1
WHERE datetime_column='2010-01-01 00:00:00'
started to add extra character set conversion:
SELECT * FROM t1
WHERE CONVERT(datetime_column USING cp850)='2010-01-01 00:00:00';
so index on DATETIME column was not used anymore.
Fix:
avoid convertion of NUMERIC/DATETIME items
(i.e. those with derivation DERIVATION_NUMERIC).
There were two problems here:
1. misleading error message
2. abusing KILL QUERY in the test case
1. The server reported "'DELETE FROM t1' failed: 1689: Wait on a lock was
aborted due to a pending exclusive lock", while the proper error message
should be "'DELETE FROM t1' failed: 1317: Query execution was interrupted".
The problem is that the server has two different flags for
signalling that a query is being killed: THD::killed and
mysys_var::abort. The test case triggers a race: sometimes
mysys_var::abort is set earlier than THD::killed. That leads
to the following situation:
- thr_lock() checks mysys_var::abort and returns error status,
since mysys_var::abort is set;
- the caller (mysql_lock_tables()) gets an error from thr_lock(),
but THD::killed is not set, so it decides that thr_lock() couldn't
get a lock due to a pending exclusive lock.
This is a known issue with the server and it's not going to be fixed soon.
5.5 differs from 5.1 here as follows: when thr_lock() returns an error:
- 5.1 continues trying thr_lock() until success;
- 5.5 propagates the error
2. The test case uses KILL QUERY is a highly concurent environment.
The fix is to wait for the dying statement to rest in peace before
executing another DELETE FROM t1.
Fix for bug #46947 "Embedded SELECT without FOR UPDATE is
causing a lock", with after-review fixes.
SELECT statements with subqueries referencing InnoDB tables
were acquiring shared locks on rows in these tables when they
were executed in REPEATABLE-READ mode and with statement or
mixed mode binary logging turned on.
This was a regression which were introduced when fixing
bug 39843.
The problem was that for tables belonging to subqueries
parser set TL_READ_DEFAULT as a lock type. In cases when
statement/mixed binary logging at open_tables() time this
type of lock was converted to TL_READ_NO_INSERT lock at
open_tables() time and caused InnoDB engine to acquire
shared locks on reads from these tables. Although in some
cases such behavior was correct (e.g. for subqueries in
DELETE) in case of SELECT it has caused unnecessary locking.
This patch tries to solve this problem by rethinking our
approach to how we handle locking for SELECT and subqueries.
Now we always set TL_READ_DEFAULT lock type for all cases
when we read data. When at open_tables() time this lock
is interpreted as TL_READ_NO_INSERT or TL_READ depending
on whether this statement as a whole or call to function
which uses particular table should be written to the
binary log or not (if yes then statement should be properly
serialized with concurrent statements and stronger lock
should be acquired).
Test coverage is added for both InnoDB and MyISAM.
This patch introduces an "incompatible" change in locking
scheme for subqueries used in SELECT ... FOR UPDATE and
SELECT .. IN SHARE MODE.
In 4.1 the server would use a snapshot InnoDB read for
subqueries in SELECT FOR UPDATE and SELECT .. IN SHARE MODE
statements, regardless of whether the binary log is on or off.
If the user required a different type of read (i.e. locking read),
he/she could request so explicitly by providing FOR UPDATE/IN SHARE MODE
clause for each individual subquery.
On of the patches for 5.0 broke this behaviour (which was not documented
or tested), and started to use locking reads fora all subqueries in SELECT ...
FOR UPDATE/IN SHARE MODE. This patch restored 4.1 behaviour.
mysql-test/include/check_concurrent_insert.inc:
Added auxiliary script which allows to check if statement
reading table allows concurrent inserts in it.
mysql-test/include/check_no_concurrent_insert.inc:
Added auxiliary script which allows to check that statement
reading table doesn't allow concurrent inserts in it.
mysql-test/include/check_no_row_lock.inc:
Added auxiliary script which allows to check if statement
reading table doesn't take locks on its rows.
mysql-test/include/check_shared_row_lock.inc:
Added auxiliary script which allows to check if statement
reading table takes shared locks on some of its rows.
mysql-test/r/bug39022.result:
After bug #46947 'Embedded SELECT without FOR UPDATE is
causing a lock' was fixed test case for bug 39022 has to
be adjusted in order to trigger execution path on which
original problem was encountered.
mysql-test/r/innodb_mysql_lock2.result:
Added coverage for handling of locking in various cases when
we read data from InnoDB tables (includes test case for
bug #46947 'Embedded SELECT without FOR UPDATE is causing a
lock').
mysql-test/r/lock_sync.result:
Added coverage for handling of locking in various cases when
we read data from MyISAM tables.
mysql-test/t/bug39022.test:
After bug #46947 'Embedded SELECT without FOR UPDATE is
causing a lock' was fixed test case for bug 39022 has to
be adjusted in order to trigger execution path on which
original problem was encountered.
mysql-test/t/innodb_mysql_lock2.test:
Added coverage for handling of locking in various cases when
we read data from InnoDB tables (includes test case for
bug #46947 'Embedded SELECT without FOR UPDATE is causing a
lock').
mysql-test/t/lock_sync.test:
Added coverage for handling of locking in various cases when
we read data from MyISAM tables.
sql/log_event.cc:
Since LEX::lock_option member was removed we no longer can
rely on its value in Load_log_event::print_query() to
determine that log event correponds to LOAD DATA CONCURRENT
statement (this was not correct in all situations anyway).
A new Load_log_event's member was introduced as a replacement.
It is initialized at event object construction time and
explicitly indicates whether LOAD DATA was concurrent.
sql/log_event.h:
Since LEX::lock_option member was removed we no longer can
rely on its value in Load_log_event::print_query() to
determine that log event correponds to LOAD DATA CONCURRENT
statement (this was not correct in all situations anyway).
A new Load_log_event's member was introduced as a replacement.
It is initialized at event object construction time and
explicitly indicates whether LOAD DATA was concurrent.
sql/sp_head.cc:
sp_head::reset_lex():
Before parsing substatement reset part of parser state
which needs this (e.g. set Yacc_state::m_lock_type to
default value).
sql/sql_acl.cc:
Since LEX::reset_n_backup_query_tables_list() now also
resets LEX::sql_command member (as it became part of
Query_tables_list class) we have to restore it in cases
when while working with proxy Query_table_list we assume
that LEX::sql_command still corresponds to original SQL
command being executed (for example, when we are logging
statement to the binary log while having Query_tables_list
reset and backed up).
sql/sql_base.cc:
Changed read_lock_type_for_table() to return a weak TL_READ
type of lock in cases when we are executing statement which
won't update tables directly and table doesn't belong to
statement's prelocking list and thus can't be used by a
stored function. It is OK to do so since in this case table
won't be used by statement or function call which will be
written to the binary log, so serializability requirements
for it can be relaxed.
One of results from this change is that SELECTs on InnoDB
tables no longer takes shared row locks for tables which
are used in subqueries (i.e. bug #46947 is fixed).
Another result is that for similar SELECTs on MyISAM tables
concurrent inserts are allowed.
In order to implement this change signature of
read_lock_type_for_table() function was changed to take
pointers to Query_tables_list and TABLE_LIST objects.
sql/sql_base.h:
- Function read_lock_type_for_table() now takes pointers
to Query_tables_list and TABLE_LIST elements as its
arguments since to correctly determine lock type it needs
to know what statement is being performed and whether table
element for which lock type to be determined belongs to
prelocking list.
sql/sql_lex.cc:
- Removed LEX::lock_option and st_select_lex::lock_option
members. Places in parser that were using them now use
Yacc_state::m_lock_type instead.
- To emphasize that LEX::sql_command member is used during
process of opening and locking of tables it was moved to
Query_tables_list class. It is now reset by
Query_tables_list::reset_query_tables_list() method.
sql/sql_lex.h:
- Removed st_select_lex::lock_option member as there is no
real need for per-SELECT lock type (HIGH_PRIORITY option
should apply to the whole statement. FOR UPDATE/LOCK IN
SHARE MODE clauses can be handled without this member).
The main effect which was achieved by introduction of this
member, i.e. using TL_READ_DEFAULT lock type for
subqueries, is now achieved by setting LEX::lock_option
(or rather its replacement - Yacc_state::m_lock_type) to
TL_READ_DEFAULT in almost all cases.
- To emphasize that LEX::sql_command member is used during
process of opening and locking of tables it was moved to
Query_tables_list class.
- Replaced LEX::lock_option with Yacc_state::m_lock_type
in order to emphasize that this value is relevant only
during parsing. Unlike for LEX::lock_option the default
value for Yacc_state::m_lock_type is TL_READ_DEFAULT.
Note that for cases when it is OK to take a "weak" read
lock (e.g. simple SELECT) this lock type will be converted
to TL_READ at open_tables() time. So this change won't
cause negative change in behavior for such statements.
OTOH this change ensures that, for example, for SELECTs
which are used in stored functions TL_READ_NO_INSERT lock
is taken when necessary and as result calls to such stored
functions can be written to the binary log with correct
serialization.
sql/sql_load.cc:
Load_log_event constructor now requires a parameter that
indicates whether LOAD DATA is concurrent.
sql/sql_parse.cc:
LEX::lock_option was replaced with Yacc_state::m_lock_type.
And instead of resetting the latter implicitly in
mysql_init_multi_delete() we do it explicitly in the
places in parser which call this function.
sql/sql_priv.h:
- To be able more easily distinguish high-priority SELECTs
in st_select_lex::print() method added flag for
HIGH_PRIORITY option.
sql/sql_select.cc:
Changed code not to rely on LEX::lock_option to determine
that it is high-priority SELECT. It was replaced with
Yacc_state::m_lock_type which is accessible only at
parse time. So instead of LEX::lock_option we now rely
on a newly introduced flag for st_select_lex::options -
SELECT_HIGH_PRIORITY.
sql/sql_show.cc:
Since LEX::reset_n_backup_query_tables_list() now also
resets LEX::sql_command member (as it became part of
Query_tables_list class) we have to restore it in cases
when while working with proxy Query_table_list we assume
that LEX::sql_command still corresponds to original SQL
command being executed.
sql/sql_table.cc:
Since LEX::reset_query_tables_list() now also resets
LEX::sql_command member (as it became part of
Query_tables_list class) we have to restore value of this
member when this method is called by mysql_admin_table(),
to make this code safe for re-execution.
sql/sql_trigger.cc:
Since LEX::reset_n_backup_query_tables_list() now also
resets LEX::sql_command member (as it became part of
Query_tables_list class) we have to restore it in cases
when while working with proxy Query_table_list we assume
that LEX::sql_command still corresponds to original SQL
command being executed (for example, when we are logging
statement to the binary log while having Query_tables_list
reset and backed up).
sql/sql_update.cc:
Function read_lock_type_for_table() now takes pointers
to Query_tables_list and TABLE_LIST elements as its
arguments since to correctly determine lock type it needs
to know what statement is being performed and whether table
element for which lock type to be determined belongs to
prelocking list.
sql/sql_yacc.yy:
- Removed st_select_lex::lock_option member as there is no
real need for per-SELECT lock type (HIGH_PRIORITY option
should apply to the whole statement. FOR UPDATE/LOCK IN
SHARE MODE clauses can be handled without this member).
The main effect which was achieved by introduction of this
member, i.e. using TL_READ_DEFAULT lock type for
subqueries, is now achieved by setting LEX::lock_option
(or rather its replacement - Yacc_state::m_lock_type) to
TL_READ_DEFAULT in almost all cases.
- Replaced LEX::lock_option with Yacc_state::m_lock_type
in order to emphasize that this value is relevant only
during parsing. Unlike for LEX::lock_option the default
value for Yacc_state::m_lock_type is TL_READ_DEFAULT.
Note that for cases when it is OK to take a "weak" read
lock (e.g. simple SELECT) this lock type will be converted
to TL_READ at open_tables() time. So this change won't
cause negative change in behavior for such statements.
OTOH this change ensures that, for example, for SELECTs
which are used in stored functions TL_READ_NO_INSERT lock
is taken when necessary and as result calls to such stored
functions can be written to the binary log with correct
serialization.
- To be able more easily distinguish high-priority SELECTs
in st_select_lex::print() method we now use new flag
in st_select_lex::options bit-field.
Stored routine DDL statements use statement-based replication
regardless of the current binlog format. The problem here was
that if a DDL statement failed during metadata lock acquisition
or opening of mysql.proc, the binlog format would not be reset
before returning. So the following DDL or DML statements are
binlogged with a wrong binlog format, which causes the slave
to stop.
The problem can be resolved by grabbing an exclusive MDL lock firstly
instead of clearing the current binlog format. So that the binlog
format will not be affected when the lock grab returns directly with
an error. The same way is taken to open a proc table for update.
mysql-test/suite/rpl/r/rpl_tmp_table_and_DDL.result:
Test Result for bug#51839
mysql-test/suite/rpl/t/rpl_tmp_table_and_DDL.test:
Added test to make sure the binlog format is not changed
after a execution of DDL with a table locked.
sql/sp.cc:
Grab an exclusive MDL lock and open a proc table for update firstly
instead of clearing the current binlog format.
parallel mode
The failure has nothing to do with parallel, but rather on the
order the tests are executed. In this case, the test
binlog_tmp_table (lets call it test2) was not ensuring that the
binary logs would be reset when it started. Later the test issues
a mysqlbinlog .../master-bin.000002 | mysql ... If the test that
was executed before this one (lets call it test1) had issued a
flush logs, then the file in use in test1 (master-bin.000002)
would not actually match the one that was expected. Eventually,
this would cause the statements logged in test1 to be replayed,
instead of the ones logged in the beginning of test2.
We fix this by:
1. adding RESET MASTER to the beginning of binlog_tmp_table
2. setting dynamically the file to use in binlog_tmp_table
Only #1 was needed, but the two make the tests cases more robust.
Statements with CONNECTION_ID were forced to be kept in the transactional
cache and by consequence non-transactional changes that were supposed to
be flushed ahead of the transaction were kept in the transactional cache.
This happened because after BUG#51894 any statement whose thd's
thread_specific_used was set was kept in the transactional cache. The idea
was to keep changes on temporary tables in the transactional cache. However,
the thread_specific_used was set not only for statements that accessed
temporary tables but also when the CONNECTION_ID was used.
To fix the problem, we created a new variable to keep track of updates
to temporary tables.
mysql-test/suite/rpl/r/rpl_temp_temporary.result:
Added a test case.
mysql-test/suite/rpl/t/rpl_temp_temporary.test:
Added a test case.
sql/log_event.cc:
Uses the thread_temporary_used to decide if a statement should
be kept in the transactional cache or not.
sql/sql_class.cc:
Sets the thread_temporary_used while calling the decide_logging_format.
sql/sql_class.h:
Defines the thread_temporary_used.
sql/sql_parse.cc:
Resets the thread_temporary_used.
transaction
BUG#52616 Temp table prevents switch binlog format from STATEMENT to ROW
Post-merge fixes.
mysql-test/include/commit.inc:
Changed the test case as drop temporary is now written to the binary log in row mode.
mysql-test/r/commit_1innodb.result:
Changed the test case as drop temporary is now written to the binary log in row mode.
mysql-test/r/ctype_cp932_binlog_stm.result:
Disabled warning messages because the test runs in both statement and mixed modes.
mysql-test/t/ctype_cp932_binlog_stm.test:
Disabled warning messages because the test runs in both statement and mixed modes.
mysql-test/t/mysqlbinlog.test:
Removed the --short-form due to BUG#18337 what was suppressing the
select * from t5 /* must be (1),(1) */ in row format.
transaction
BUG#52616 Temp table prevents switch binlog format from STATEMENT to ROW
Before the WL#2687 and BUG#46364, every non-transactional change that happened
after a transactional change was written to trx-cache and flushed upon
committing the transaction. WL#2687 and BUG#46364 changed this behavior and
non-transactional changes are now written to the binary log upon committing
the statement.
A binary log event is identified as transactional or non-transactional through
a flag in the Log_event which is set taking into account the underlie storage
engine on what it is stems from. In the current bug, this flag was not being
set properly when the DROP TEMPORARY TABLE was executed.
However, while fixing this bug we figured out that changes to temporary tables
should be always written to the trx-cache if there is an on-going transaction.
Otherwise, binlog events in the reversed order would be produced.
Regarding concurrency, keeping changes to temporary tables in the trx-cache is
also safe as temporary tables are only visible to the owner connection.
In this patch, we classify the following statements as unsafe:
1 - INSERT INTO t_myisam SELECT * FROM t_myisam_temp
2 - INSERT INTO t_myisam_temp SELECT * FROM t_myisam
3 - CREATE TEMPORARY TABLE t_myisam_temp SELECT * FROM t_myisam
On the other hand, the following statements are classified as safe:
1 - INSERT INTO t_innodb SELECT * FROM t_myisam_temp
2 - INSERT INTO t_myisam_temp SELECT * FROM t_innodb
The patch also guarantees that transactions that have a DROP TEMPORARY are
always written to the binary log regardless of the mode and the outcome:
commit or rollback. In particular, the DROP TEMPORARY is extended with the
IF EXISTS clause when the current statement logging format is set to row.
Finally, the patch allows to switch from STATEMENT to MIXED/ROW when there
are temporary tables but the contrary is not possible.
mysql-test/extra/rpl_tests/rpl_binlog_max_cache_size.test:
Updated the test case because
CREATE TEMPORARY TABLE t_innodb_temp SELECT * FROM t_myisam is not unsafe.
mysql-test/extra/rpl_tests/rpl_implicit_commit_binlog.test:
Updated the test case due to the new rules: changes to
temporary tables are written to the binary log in the
boundaries of a transaction if there is any.
mysql-test/extra/rpl_tests/rpl_innodb.test:
Removed comments from the test case that became false after the patch.
mysql-test/extra/rpl_tests/rpl_loaddata.test:
Suppressed warning messages due to the following cases:
1 - INSERT INTO t_myisam SELECT * FROM t_myisam_temp
2 - INSERT INTO t_myisam_temp SELECT * FROM t_myisam
mysql-test/include/ctype_utf8_table.inc:
Suppressed warning messages due to the following cases:
1 - INSERT INTO t_myisam SELECT * FROM t_myisam_temp
2 - INSERT INTO t_myisam_temp SELECT * FROM t_myisam
mysql-test/r/ctype_cp932_binlog_stm.result:
Updated the test case due to the new rules: changes to
temporary tables are written to the binary log in the
boundaries of a transaction if there is any.
mysql-test/suite/binlog/r/binlog_database.result:
Updated the test case due to the new rules: changes to
temporary tables are written to the binary log in the
boundaries of a transaction if there is any.
mysql-test/suite/binlog/r/binlog_innodb_row.result:
Updated the result file.
mysql-test/suite/binlog/r/binlog_multi_engine.result:
Updated the unsafe message.
mysql-test/suite/binlog/r/binlog_row_binlog.result:
Updated the test case due to the new rules: changes to
temporary tables are written to the binary log in the
boundaries of a transaction if there is any.
mysql-test/suite/binlog/r/binlog_row_drop_tmp_tbl.result:
Updated the test case due to the new rules: changes to
temporary tables are written to the binary log in the
boundaries of a transaction if there is any.
mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result:
Updated the test case due to the new rules: changes to
temporary tables are written to the binary log in the
boundaries of a transaction if there is any.
mysql-test/suite/binlog/r/binlog_stm_binlog.result:
Updated the result file.
mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result:
Updated the test case due to the new rules: changes to
temporary tables are written to the binary log in the
boundaries of a transaction if there is any.
mysql-test/suite/binlog/t/binlog_tmp_table.test:
Suppressed warning messages due to the following cases:
1 - INSERT INTO t_myisam SELECT * FROM t_myisam_temp
2 - INSERT INTO t_myisam_temp SELECT * FROM t_myisam
mysql-test/suite/ndb/r/ndb_binlog_format.result:
Updated the unsafe message.
mysql-test/suite/rpl/r/rpl_concurrency_error.result:
Updated the unsafe message.
mysql-test/suite/rpl/r/rpl_mixed_binlog_max_cache_size.result:
Updated the result file because
CREATE TEMPORARY TABLE t_innodb_temp SELECT * FROM t_myisam is not unsafe.
mysql-test/suite/rpl/r/rpl_mixed_implicit_commit_binlog.result:
Updated the test case due to the new rules: changes to
temporary tables are written to the binary log in the
boundaries of a transaction if there is any.
mysql-test/suite/rpl/r/rpl_mixed_mixing_engines.result:
Updated the test case due to the new rules: changes to
temporary tables are written to the binary log in the
boundaries of a transaction if there is any.
mysql-test/suite/rpl/r/rpl_mixed_row_innodb.result:
Added some comments to ease the understanding of the result file.
mysql-test/suite/rpl/r/rpl_non_direct_mixed_mixing_engines.result:
Updated the test case due to the new rules: changes to
temporary tables are written to the binary log in the
boundaries of a transaction if there is any.
mysql-test/suite/rpl/r/rpl_non_direct_row_mixing_engines.result:
Updated the test case due to the new rules: changes to
temporary tables are written to the binary log in the
boundaries of a transaction if there is any.
mysql-test/suite/rpl/r/rpl_non_direct_stm_mixing_engines.result:
Updated the test case due to the new rules: changes to
temporary tables are written to the binary log in the
boundaries of a transaction if there is any.
mysql-test/suite/rpl/r/rpl_row_drop.result:
Updated the test case due to the new rules: changes to
temporary tables are written to the binary log in the
boundaries of a transaction if there is any.
mysql-test/suite/rpl/r/rpl_row_implicit_commit_binlog.result:
Updated the test case due to the new rules: changes to
temporary tables are written to the binary log in the
boundaries of a transaction if there is any.
mysql-test/suite/rpl/r/rpl_row_mixing_engines.result:
Updated the test case due to the new rules: changes to
temporary tables are written to the binary log in the
boundaries of a transaction if there is any.
mysql-test/suite/rpl/r/rpl_stm_binlog_max_cache_size.result:
Updated the result file because
CREATE TEMPORARY TABLE t_innodb_temp SELECT * FROM t_myisam is not unsafe.
mysql-test/suite/rpl/r/rpl_stm_implicit_commit_binlog.result:
Updated the test case due to the new rules: changes to
temporary tables are written to the binary log in the
boundaries of a transaction if there is any.
mysql-test/suite/rpl/r/rpl_stm_innodb.result:
Added some comments to ease the understanding of the result file.
mysql-test/suite/rpl/r/rpl_stm_mixing_engines.result:
Updated the test case due to the new rules: changes to
temporary tables are written to the binary log in the
boundaries of a transaction if there is any.
mysql-test/suite/rpl/r/rpl_stm_stop_middle_group.result:
Updated the unsafe message.
mysql-test/suite/rpl/r/rpl_temp_temporary.result:
Added a test case.
mysql-test/suite/rpl/t/rpl000013.test:
Suppressed warning messages due to the following cases:
1 - INSERT INTO t_myisam SELECT * FROM t_myisam_temp
2 - INSERT INTO t_myisam_temp SELECT * FROM t_myisam
3 - CREATE TEMPORARY TABLE t_myisam_temp SELECT * FROM t_myisam
mysql-test/suite/rpl/t/rpl_misc_functions.test:
Suppressed warning messages.
mysql-test/suite/rpl/t/rpl_temp_table.test:
Suppressed warning messages due to the following cases:
1 - INSERT INTO t_myisam SELECT * FROM t_myisam_temp
2 - INSERT INTO t_myisam_temp SELECT * FROM t_myisam
3 - CREATE TEMPORARY TABLE t_myisam_temp SELECT * FROM t_myisam
mysql-test/suite/rpl/t/rpl_temp_temporary.test:
Added a test case.
mysql-test/suite/rpl/t/rpl_temporary.test:
Suppressed warning messages due to the following cases:
1 - INSERT INTO t_myisam SELECT * FROM t_myisam_temp
2 - INSERT INTO t_myisam_temp SELECT * FROM t_myisam
3 - CREATE TEMPORARY TABLE t_myisam_temp SELECT * FROM t_myisam
mysql-test/suite/rpl_ndb/r/rpl_ndb_row_implicit_commit_binlog.result:
Updated the test case due to the new rules: changes to
temporary tables are written to the binary log in the
boundaries of a transaction if there is any.
mysql-test/suite/rpl_ndb/r/rpl_truncate_7ndb.result:
Updated the test case to remove references to positions
in the binary log.
mysql-test/suite/rpl_ndb/t/rpl_truncate_7ndb.test:
Updated the test case to remove references to positions
in the binary log.
mysql-test/t/create_select_tmp.test:
Suppressed warning messages due to the following cases:
1 - INSERT INTO t_myisam SELECT * FROM t_myisam_temp
2 - INSERT INTO t_myisam_temp SELECT * FROM t_myisam
3 - CREATE TEMPORARY TABLE t_myisam_temp SELECT * FROM t_myisam
mysql-test/t/ctype_cp932_binlog_stm.test:
Suppressed warning messages due to the following cases:
1 - INSERT INTO t_myisam SELECT * FROM t_myisam_temp
2 - INSERT INTO t_myisam_temp SELECT * FROM t_myisam
3 - CREATE TEMPORARY TABLE t_myisam_temp SELECT * FROM t_myisam
mysql-test/t/mysqlbinlog.test:
Suppressed warning messages due to the following cases:
1 - INSERT INTO t_myisam SELECT * FROM t_myisam_temp
2 - INSERT INTO t_myisam_temp SELECT * FROM t_myisam
3 - CREATE TEMPORARY TABLE t_myisam_temp SELECT * FROM t_myisam
sql/log.cc:
Improved the code by creating several functions to hide decision
on type of engine changed, commit/abort, etc:
. stmt_has_updated_non_trans_table
. trans_has_updated_non_trans_table
. ending_trans
Updated the binlog_rollback function and the use of the
OPTION_KEEP_LOG which indincates when a temporary table was
either created or dropped and as such the command must be
logged if not in MIXED mode and even while rolling back the
transaction.
sql/log.h:
Improved the code by creating several functions to hide decision
on type of engine changed, commit/abort, etc.
sql/log_event.cc:
Removed the setting of the OPTION_KEEP_LOG as it is related to CREATE
TEMPORARY and DROP TEMPORARY and not to the type of engine (i.e.
transactional or non-transactional).
sql/log_event_old.cc:
Removed the setting of the OPTION_KEEP_LOG as it is related to CREATE
TEMPORARY and DROP TEMPORARY and not to the type of engine (i.e.
transactional or non-transactional).
sql/share/errmsg-utf8.txt:
Updated the unsafe message.
sql/sql_class.cc:
Classifies the following statements as unsafe:
1 - INSERT INTO t_myisam SELECT * FROM t_myisam_temp
2 - INSERT INTO t_myisam_temp SELECT * FROM t_myisam
On the other hand, the following statements are classified as safe:
1 - INSERT INTO t_innodb SELECT * FROM t_myisam_temp
2 - INSERT INTO t_myisam_temp SELECT * FROM t_innodb
sql/sql_class.h:
It allows to switch from STATEMENT to MIXED/ROW when there are temporary
tables but the contrary is not possible.
sql/sql_table.cc:
Fixed the case that a DROP/DROP TEMPORARY that affects a temporary table in MIXED
mode is written as a DROP TEMPORARY TABLE IF EXISTS because the table may not exist in the slave and due to the IF EXISTS token an error will never happen
while processing the statement in the slave.
Removed a function that was not being used.
This assertion could be triggered during execution of OPTIMIZE TABLE for
InnoDB tables. As part of optimize for InnoDB tables, the table is recreated
and then opened again. If the reopen failed for any reason, the assertion
would be triggered. This could for example be caused by a concurrent DROP
TABLE executed by a different connection. The reason for the assertion was
that any failures during reopening were ignored.
This patch fixes the problem by making sure that the result of reopening the
table is checked and that any error messages are sent to the client.
Test case added to innodb_mysql_sync.test.
This was a deadlock between CREATE/ALTER/DROP EVENT and a query
accessing both the mysql.event table and I_S.GLOBAL_VARIABLES.
The root of the problem was that the LOCK_event_metadata mutex was
used to both protect the "event_scheduler" global system variable
and the internal event data structures used by CREATE/ALTER/DROP EVENT.
The deadlock would occur if CREATE/ALTER/DROP EVENT held
LOCK_event_metadata while trying to open the mysql.event table,
at the same time as the query had mysql.event open, trying to
lock LOCK_event_metadata to access "event_scheduler".
This bug was fixed in the scope of Bug#51160 by using only
LOCK_global_system_variables to protect "event_scheduler".
This makes it so that the query above won't lock LOCK_event_metadata,
thereby preventing this deadlock from occuring.
This patch contains no code changes.
Test case added to lock_sync.test.
even if myisam-recover is OFF
The problem was that a corrupted MyISAM table was auto repaired
even if the myisam_recover_options server variable (or the
myisam_recover option) was set to OFF.
The reason was that the auto_repair() function, which is supposed
to say if auto repair is to be used, did not use the server variable
setting correctly. This bug was a regression introduced by WL#4738.
This patch fixes the problem by making sure auto_repair() returns
FALSE if myisam_recover_options is set to OFF.
Test case added to myisam.test.
