2006-03-24 14:58:18 +03:00
|
|
|
drop table if exists t1;
|
|
|
|
create table t1 (a varchar(16), b int) engine=innodb;
|
|
|
|
create trigger t1_bi before insert on t1 for each row
|
|
|
|
begin
|
|
|
|
set new.a := upper(new.a);
|
|
|
|
set new.b := new.b + 3;
|
|
|
|
end|
|
|
|
|
select trigger_schema, trigger_name, event_object_schema,
|
|
|
|
event_object_table, action_statement from information_schema.triggers
|
|
|
|
where event_object_schema = 'test' and event_object_table = 't1';
|
|
|
|
trigger_schema trigger_name event_object_schema event_object_table action_statement
|
|
|
|
test t1_bi test t1 begin
|
|
|
|
set new.a := upper(new.a);
|
|
|
|
set new.b := new.b + 3;
|
|
|
|
end
|
|
|
|
insert into t1 values ('The Lion', 10);
|
|
|
|
select * from t1;
|
|
|
|
a b
|
|
|
|
THE LION 13
|
|
|
|
optimize table t1;
|
|
|
|
Table Op Msg_type Msg_text
|
Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
partition is corrupt
The main problem was that ALTER TABLE t ANALYZE/CHECK/OPTIMIZE/REPAIR
PARTITION took another code path (over mysql_alter_table instead of
mysql_admin_table) which differs in two ways:
1) alter table opens the tables in a different way than admin tables do
resulting in returning with error before it tried the command
2) alter table does not start to send any diagnostic rows to the client
which the lower admin functions continue to use -> resulting in
assertion crash
The fix:
Remapped ALTER TABLE t ANALYZE/CHECK/OPTIMIZE/REPAIR PARTITION to use
the same code path as ANALYZE/CHECK/OPTIMIZE/REPAIR TABLE t.
Adding check in mysql_admin_table to setup the partition list for
which partitions that should be used.
Partitioned tables will still not work with
REPAIR TABLE/PARTITION USE_FRM, since that requires moving partitions
to tables, REPAIR TABLE t USE_FRM, and check that the data still
fulfills the partitioning function and then move the table back to
being a partition.
NOTE: I have removed the following functions from the handler
interface:
analyze_partitions, check_partitions, optimize_partitions,
repair_partitions
Since they are not longer needed.
THIS ALTERS THE STORAGE ENGINE API
mysql-test/r/handler_innodb.result:
Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
partition is corrupt
Added a note result row.
mysql-test/r/innodb.result:
Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
partition is corrupt
Added a note result row.
mysql-test/r/innodb_mysql.result:
Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
partition is corrupt
Added a note result row.
mysql-test/r/partition.result:
Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
partition is corrupt
Updated after fixing ANALYZE/CHECK/OPTIMIZE/REPAIR partitioned
tables.
mysql-test/r/trigger-trans.result:
Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
partition is corrupt
Added a note result row.
mysql-test/suite/ndb/r/ndb_partition_key.result:
Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
partition is corrupt
Updated after fixing ANALYZE/CHECK/OPTIMIZE/REPAIR partitioned
tables.
mysql-test/suite/ndb/t/ndb_partition_key.test:
Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
partition is corrupt
Updated after fixing ANALYZE/CHECK/OPTIMIZE/REPAIR partitioned
tables.
mysql-test/suite/parts/inc/partition_alter4.inc:
Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
partition is corrupt
Updated after fixing ANALYZE/CHECK/OPTIMIZE/REPAIR partitioned
tables.
mysql-test/suite/parts/r/partition_alter4_innodb.result:
Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
partition is corrupt
Updated after fixing ANALYZE/CHECK/OPTIMIZE/REPAIR partitioned
tables.
mysql-test/suite/parts/r/partition_alter4_myisam.result:
Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
partition is corrupt
Updated after fixing ANALYZE/CHECK/OPTIMIZE/REPAIR partitioned
tables.
mysql-test/suite/rpl/r/rpl_failed_optimize.result:
Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
partition is corrupt
Added a note result row.
mysql-test/suite/rpl/r/rpl_innodb_mixed_dml.result:
Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
partition is corrupt
Added a note result row.
mysql-test/t/partition.test:
Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
partition is corrupt
Updated after fixing ANALYZE/CHECK/OPTIMIZE/REPAIR partitioned
tables.
sql/ha_partition.cc:
Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
partition is corrupt
Added a function for returning admin commands result rows
Updated handle_opt_partitions to handle admin commands result rows,
and some error filtering (as mysql_admin_table do).
Removed the functions analyze/check/optimize/repair_partitions
since they have no longer any use.
sql/ha_partition.h:
Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
partition is corrupt
Removed analyze/check/optimize/repair_partitions since they
are no longer are needed.
sql/handler.cc:
Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
partition is corrupt
Removed analyze/check/optimize/repair_partitions since they
are no longer are needed.
sql/handler.h:
Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
partition is corrupt
Removed analyze/check/optimize/repair_partitions since they
are no longer are needed.
sql/mysql_priv.h:
Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
partition is corrupt
Added set_part_state for reuse of code in mysql_admin_table.
(Originally fond in sql/sql_partition.cc:prep_alter_part_table)
sql/protocol.cc:
Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
partition is corrupt
Added one assert and a debug print.
sql/sql_partition.cc:
Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
partition is corrupt
Refactored code for setting up partition state, set_part_state,
now used in both prep_alter_part_table and
sql_table.cc:mysql_admin_table.
Removed code for handling ANALYZE/CHECK/OPTIMIZE/REPAIR partitions,
since it is now handled by mysql_admin_table.
sql/sql_table.cc:
Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
partition is corrupt
Added functionality in mysql_admin_table to work with partitioned
tables.
Fixed a possible assertion bug for HA_ADMIN_TRY_ALTER
(If analyze would output a row, it fails since the row was already
started).
sql/sql_yacc.yy:
Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
partition is corrupt
Remapped ALTER TABLE t ANALYZE/CHECK/OPTIMIZE/REPAIR PARTITION
to use the same code path as ANALYZE/CHECK/OPTIMIZE/REPAIR TABLE
instead of taking the ALTER TABLE path.
Added reset of alter_info for ANALYZE/CHECK/OPTIMIZE/REPAIR TABLE
since it is now used by partitioned tables.
storage/myisam/mi_check.c:
Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
partition is corrupt
Changed warning message from "Found X parts Should be: Y parts"
to "Found X key parts. Should be Y", since it could be confusing
with partitioned tables.
2008-08-11 20:02:03 +02:00
|
|
|
test.t1 optimize note Table does not support optimize, doing recreate + analyze instead
|
2006-03-24 14:58:18 +03:00
|
|
|
test.t1 optimize status OK
|
|
|
|
select trigger_schema, trigger_name, event_object_schema,
|
|
|
|
event_object_table, action_statement from information_schema.triggers
|
|
|
|
where event_object_schema = 'test' and event_object_table = 't1';
|
|
|
|
trigger_schema trigger_name event_object_schema event_object_table action_statement
|
|
|
|
test t1_bi test t1 begin
|
|
|
|
set new.a := upper(new.a);
|
|
|
|
set new.b := new.b + 3;
|
|
|
|
end
|
|
|
|
insert into t1 values ('The Unicorn', 20);
|
|
|
|
select * from t1;
|
|
|
|
a b
|
|
|
|
THE LION 13
|
|
|
|
THE UNICORN 23
|
|
|
|
alter table t1 add column c int default 0;
|
|
|
|
select trigger_schema, trigger_name, event_object_schema,
|
|
|
|
event_object_table, action_statement from information_schema.triggers
|
|
|
|
where event_object_schema = 'test' and event_object_table = 't1';
|
|
|
|
trigger_schema trigger_name event_object_schema event_object_table action_statement
|
|
|
|
test t1_bi test t1 begin
|
|
|
|
set new.a := upper(new.a);
|
|
|
|
set new.b := new.b + 3;
|
|
|
|
end
|
|
|
|
insert into t1 values ('Alice', 30, 1);
|
|
|
|
select * from t1;
|
|
|
|
a b c
|
|
|
|
THE LION 13 0
|
|
|
|
THE UNICORN 23 0
|
|
|
|
ALICE 33 1
|
|
|
|
alter table t1 rename to t1;
|
|
|
|
select trigger_schema, trigger_name, event_object_schema,
|
|
|
|
event_object_table, action_statement from information_schema.triggers
|
|
|
|
where event_object_schema = 'test' and event_object_table = 't1';
|
|
|
|
trigger_schema trigger_name event_object_schema event_object_table action_statement
|
|
|
|
test t1_bi test t1 begin
|
|
|
|
set new.a := upper(new.a);
|
|
|
|
set new.b := new.b + 3;
|
|
|
|
end
|
|
|
|
insert into t1 values ('The Crown', 40, 1);
|
|
|
|
select * from t1;
|
|
|
|
a b c
|
|
|
|
THE LION 13 0
|
|
|
|
THE UNICORN 23 0
|
|
|
|
ALICE 33 1
|
|
|
|
THE CROWN 43 1
|
|
|
|
alter table t1 rename to t1, add column d int default 0;
|
|
|
|
select trigger_schema, trigger_name, event_object_schema,
|
|
|
|
event_object_table, action_statement from information_schema.triggers
|
|
|
|
where event_object_schema = 'test' and event_object_table = 't1';
|
|
|
|
trigger_schema trigger_name event_object_schema event_object_table action_statement
|
|
|
|
test t1_bi test t1 begin
|
|
|
|
set new.a := upper(new.a);
|
|
|
|
set new.b := new.b + 3;
|
|
|
|
end
|
|
|
|
insert into t1 values ('The Pie', 50, 1, 1);
|
|
|
|
select * from t1;
|
|
|
|
a b c d
|
|
|
|
THE LION 13 0 0
|
|
|
|
THE UNICORN 23 0 0
|
|
|
|
ALICE 33 1 0
|
|
|
|
THE CROWN 43 1 0
|
|
|
|
THE PIE 53 1 1
|
|
|
|
drop table t1;
|
A fix and a test case for Bug#26141 mixing table types in trigger
causes full table lock on innodb table.
Also fixes Bug#28502 Triggers that update another innodb table
will block on X lock unnecessarily (duplciate).
Code review fixes.
Both bugs' synopses are misleading: InnoDB table is
not X locked. The statements, however, cannot proceed concurrently,
but this happens due to lock conflicts for tables used in triggers,
not for the InnoDB table.
If a user had an InnoDB table, and two triggers, AFTER UPDATE and
AFTER INSERT, competing for different resources (e.g. two distinct
MyISAM tables), then these two triggers would not be able to execute
concurrently. Moreover, INSERTS/UPDATES of the InnoDB table would
not be able to run concurrently.
The problem had other side-effects (see respective bug reports).
This behavior was a consequence of a shortcoming of the pre-locking
algorithm, which would not distinguish between different DML operations
(e.g. INSERT and DELETE) and pre-lock all the tables
that are used by any trigger defined on the subject table.
The idea of the fix is to extend the pre-locking algorithm to keep track,
for each table, what DML operation it is used for and not
load triggers that are known to never be fired.
mysql-test/r/trigger-trans.result:
Update results (Bug#26141)
mysql-test/r/trigger.result:
Update results (Bug#28502)
mysql-test/t/trigger-trans.test:
Add a test case for Bug#26141 mixing table types in trigger causes
full table lock on innodb table.
mysql-test/t/trigger.test:
Add a test case for Bug#28502 Triggers that update another innodb
table will block echo on X lock unnecessarily. Add more test
coverage for triggers.
sql/item.h:
enum trg_event_type is needed in table.h
sql/sp.cc:
Take into account table_list->trg_event_map when determining
what tables to pre-lock.
After this change, if we attempt to fire a
trigger for which we had not pre-locked any tables, error
'Table was not locked with LOCK TABLES' will be printed.
This, however, should never happen, provided the pre-locking
algorithm has no programming bugs.
Previously a trigger key in the sroutines hash was based on the name
of the table the trigger belongs to. This was possible because we would
always add to the pre-locking list all the triggers defined for a table when
handling this table.
Now the key is based on the name of the trigger, owing
to the fact that a trigger name must be unique in the database it
belongs to.
sql/sp_head.cc:
Generate sroutines hash key in init_spname(). This is a convenient
place since there we have all the necessary information and can
avoid an extra alloc.
Maintain and merge trg_event_map when adding and merging elements
of the pre-locking list.
sql/sp_head.h:
Add ,m_sroutines_key member, used when inserting the sphead for a
trigger into the cache of routines used by a statement.
Previously the key was based on the table name the trigger belonged
to, since for a given table we would add to the sroutines list
all the triggers defined on it.
sql/sql_lex.cc:
Introduce a new lex step: set_trg_event_type_for_tables().
It is called when we have finished parsing but before opening
and locking tables. Now this step is used to evaluate for each
TABLE_LIST instance which INSERT/UPDATE/DELETE operation, if any,
it is used in.
In future this method could be extended to aggregate other information
that is hard to aggregate during parsing.
sql/sql_lex.h:
Add declaration for set_trg_event_type_for_tables().
sql/sql_parse.cc:
Call set_trg_event_type_for_tables() after MYSQLparse(). Remove tabs.
sql/sql_prepare.cc:
Call set_trg_event_type_for_tables() after MYSQLparse().
sql/sql_trigger.cc:
Call set_trg_event_type_for_tables() after MYSQLparse().
sql/sql_trigger.h:
Remove an obsolete member.
sql/sql_view.cc:
Call set_trg_event_type_for_tables() after MYSQLparse().
sql/sql_yacc.yy:
Move assignment of sp_head::m_type before calling sp_head::init_spname(),
one is now used inside another.
sql/table.cc:
Implement TABLE_LIST::set_trg_event_map() - a method that calculates
wh triggers may be fired on this table when executing a statement.
sql/table.h:
Add missing declarations.
Move declaration of trg_event_type from item.h (it will be needed for
trg_event_map bitmap when we start using Bitmap template instead
of uint8).
2007-07-12 22:26:41 +04:00
|
|
|
|
|
|
|
Bug#26141 mixing table types in trigger causes full
|
|
|
|
table lock on innodb table
|
|
|
|
|
|
|
|
Ensure we do not open and lock tables for the triggers we do not
|
|
|
|
fire.
|
|
|
|
|
|
|
|
drop table if exists t1, t2, t3;
|
|
|
|
drop trigger if exists trg_bug26141_au;
|
|
|
|
drop trigger if exists trg_bug26141_ai;
|
|
|
|
create table t1 (c int primary key) engine=innodb;
|
|
|
|
create table t2 (c int) engine=myisam;
|
|
|
|
create table t3 (c int) engine=myisam;
|
|
|
|
insert into t1 (c) values (1);
|
|
|
|
create trigger trg_bug26141_ai after insert on t1
|
|
|
|
for each row
|
|
|
|
begin
|
|
|
|
insert into t2 (c) values (1);
|
|
|
|
# We need the 'sync' lock to synchronously wait in connection 2 till
|
|
|
|
# the moment when the trigger acquired all the locks.
|
|
|
|
select release_lock("lock_bug26141_sync") into @a;
|
|
|
|
# 1000 is time in seconds of lock wait timeout -- this is a way
|
|
|
|
# to cause a manageable sleep up to 1000 seconds
|
|
|
|
select get_lock("lock_bug26141_wait", 1000) into @a;
|
|
|
|
end|
|
|
|
|
create trigger trg_bug26141_au after update on t1
|
|
|
|
for each row
|
|
|
|
begin
|
|
|
|
insert into t3 (c) values (1);
|
|
|
|
end|
|
|
|
|
select get_lock("lock_bug26141_wait", 0);
|
|
|
|
get_lock("lock_bug26141_wait", 0)
|
|
|
|
1
|
|
|
|
select get_lock("lock_bug26141_sync", /* must not be priorly locked */ 0);
|
|
|
|
get_lock("lock_bug26141_sync", /* must not be priorly locked */ 0)
|
|
|
|
1
|
|
|
|
insert into t1 (c) values (2);
|
|
|
|
select get_lock("lock_bug26141_sync", 1000);
|
|
|
|
get_lock("lock_bug26141_sync", 1000)
|
|
|
|
1
|
|
|
|
update t1 set c=3 where c=1;
|
|
|
|
select release_lock("lock_bug26141_sync");
|
|
|
|
release_lock("lock_bug26141_sync")
|
|
|
|
1
|
|
|
|
select release_lock("lock_bug26141_wait");
|
|
|
|
release_lock("lock_bug26141_wait")
|
|
|
|
1
|
|
|
|
select * from t1;
|
|
|
|
c
|
|
|
|
2
|
|
|
|
3
|
|
|
|
select * from t2;
|
|
|
|
c
|
|
|
|
1
|
|
|
|
select * from t3;
|
|
|
|
c
|
|
|
|
1
|
|
|
|
drop table t1, t2, t3;
|
2008-03-12 16:13:33 +03:00
|
|
|
DROP TABLE IF EXISTS t1;
|
|
|
|
DROP TABLE IF EXISTS t2;
|
|
|
|
CREATE TABLE t1(a INT PRIMARY KEY) ENGINE=innodb;
|
|
|
|
CREATE TABLE t2(b INT, FOREIGN KEY(b) REFERENCES t1(a)) ENGINE=innodb;
|
|
|
|
INSERT INTO t1 VALUES (1);
|
|
|
|
CREATE TRIGGER t1_bd BEFORE DELETE ON t1 FOR EACH ROW SET @a = 1;
|
|
|
|
CREATE TRIGGER t1_ad AFTER DELETE ON t1 FOR EACH ROW SET @b = 1;
|
|
|
|
SET @a = 0;
|
|
|
|
SET @b = 0;
|
|
|
|
TRUNCATE t1;
|
Bug#49938: Failing assertion: inode or deadlock in fsp/fsp0fsp.c
Bug#54678: InnoDB, TRUNCATE, ALTER, I_S SELECT, crash or deadlock
- Incompatible change: truncate no longer resorts to a row by
row delete if the storage engine does not support the truncate
method. Consequently, the count of affected rows does not, in
any case, reflect the actual number of rows.
- Incompatible change: it is no longer possible to truncate a
table that participates as a parent in a foreign key constraint,
unless it is a self-referencing constraint (both parent and child
are in the same table). To work around this incompatible change
and still be able to truncate such tables, disable foreign checks
with SET foreign_key_checks=0 before truncate. Alternatively, if
foreign key checks are necessary, please use a DELETE statement
without a WHERE condition.
Problem description:
The problem was that for storage engines that do not support
truncate table via a external drop and recreate, such as InnoDB
which implements truncate via a internal drop and recreate, the
delete_all_rows method could be invoked with a shared metadata
lock, causing problems if the engine needed exclusive access
to some internal metadata. This problem originated with the
fact that there is no truncate specific handler method, which
ended up leading to a abuse of the delete_all_rows method that
is primarily used for delete operations without a condition.
Solution:
The solution is to introduce a truncate handler method that is
invoked when the engine does not support truncation via a table
drop and recreate. This method is invoked under a exclusive
metadata lock, so that there is only a single instance of the
table when the method is invoked.
Also, the method is not invoked and a error is thrown if
the table is a parent in a non-self-referencing foreign key
relationship. This was necessary to avoid inconsistency as
some integrity checks are bypassed. This is inline with the
fact that truncate is primarily a DDL operation that was
designed to quickly remove all data from a table.
mysql-test/suite/innodb/t/innodb-truncate.test:
Add test cases for truncate and foreign key checks.
Also test that InnoDB resets auto-increment on truncate.
mysql-test/suite/innodb/t/innodb.test:
FK is not necessary, test is related to auto-increment.
Update error number, truncate is no longer invoked if
table is parent in a FK relationship.
mysql-test/suite/innodb/t/innodb_mysql.test:
Update error number, truncate is no longer invoked if
table is parent in a FK relationship.
Use delete instead of truncate, test is used to check
the interaction of FKs, triggers and delete.
mysql-test/suite/parts/inc/partition_check.inc:
Fix typo.
mysql-test/suite/sys_vars/t/foreign_key_checks_func.test:
Update error number, truncate is no longer invoked if
table is parent in a FK relationship.
mysql-test/t/mdl_sync.test:
Modify test case to reflect and ensure that truncate takes
a exclusive metadata lock.
mysql-test/t/trigger-trans.test:
Update error number, truncate is no longer invoked if
table is parent in a FK relationship.
sql/ha_partition.cc:
Reorganize the various truncate methods. delete_all_rows is now
passed directly to the underlying engines, so as truncate. The
code responsible for truncating individual partitions is moved
to ha_partition::truncate_partition, which is invoked when a
ALTER TABLE t1 TRUNCATE PARTITION p statement is executed.
Since the partition truncate no longer can be invoked via
delete, the bitmap operations are not necessary anymore. The
explicit reset of the auto-increment value is also removed
as the underlying engines are now responsible for reseting
the value.
sql/handler.cc:
Wire up the handler truncate method.
sql/handler.h:
Introduce and document the truncate handler method. It assumes
certain use cases of delete_all_rows.
Add method to retrieve the list of foreign keys referencing a
table. Method is used to avoid truncating tables that are
parent in a foreign key relationship.
sql/share/errmsg-utf8.txt:
Add error message for truncate and FK.
sql/sql_lex.h:
Introduce a flag so that the partition engine can detect when
a partition is being truncated. Used to give a special error.
sql/sql_parse.cc:
Function mysql_truncate_table no longer exists.
sql/sql_partition_admin.cc:
Implement the TRUNCATE PARTITION statement.
sql/sql_truncate.cc:
Change the truncate table implementation to use the new truncate
handler method and to not rely on row-by-row delete anymore.
The truncate handler method is always invoked with a exclusive
metadata lock. Also, it is no longer possible to truncate a
table that is parent in some non-self-referencing foreign key.
storage/archive/ha_archive.cc:
Rename method as the description indicates that in the future
this could be a truncate operation.
storage/blackhole/ha_blackhole.cc:
Implement truncate as no operation for the blackhole engine in
order to remain compatible with older releases.
storage/federated/ha_federated.cc:
Introduce truncate method that invokes delete_all_rows.
This is required to support partition truncate as this
form of truncate does not implement the drop and recreate
protocol.
storage/heap/ha_heap.cc:
Introduce truncate method that invokes delete_all_rows.
This is required to support partition truncate as this
form of truncate does not implement the drop and recreate
protocol.
storage/ibmdb2i/ha_ibmdb2i.cc:
Introduce truncate method that invokes delete_all_rows.
This is required to support partition truncate as this
form of truncate does not implement the drop and recreate
protocol.
storage/innobase/handler/ha_innodb.cc:
Rename delete_all_rows to truncate. InnoDB now does truncate
under a exclusive metadata lock.
Introduce and reorganize methods used to retrieve the list
of foreign keys referenced by a or referencing a table.
storage/myisammrg/ha_myisammrg.cc:
Introduce truncate method that invokes delete_all_rows.
This is required in order to remain compatible with earlier
releases where truncate would resort to a row-by-row delete.
2010-10-06 11:34:28 -03:00
|
|
|
ERROR 42000: Cannot truncate a table referenced in a foreign key constraint (`test`.`t2`, CONSTRAINT `t2_ibfk_1` FOREIGN KEY (`b`) REFERENCES `test`.`t1` (`a`))
|
2008-03-12 16:13:33 +03:00
|
|
|
SELECT @a, @b;
|
|
|
|
@a @b
|
|
|
|
0 0
|
Bug#49938: Failing assertion: inode or deadlock in fsp/fsp0fsp.c
Bug#54678: InnoDB, TRUNCATE, ALTER, I_S SELECT, crash or deadlock
- Incompatible change: truncate no longer resorts to a row by
row delete if the storage engine does not support the truncate
method. Consequently, the count of affected rows does not, in
any case, reflect the actual number of rows.
- Incompatible change: it is no longer possible to truncate a
table that participates as a parent in a foreign key constraint,
unless it is a self-referencing constraint (both parent and child
are in the same table). To work around this incompatible change
and still be able to truncate such tables, disable foreign checks
with SET foreign_key_checks=0 before truncate. Alternatively, if
foreign key checks are necessary, please use a DELETE statement
without a WHERE condition.
Problem description:
The problem was that for storage engines that do not support
truncate table via a external drop and recreate, such as InnoDB
which implements truncate via a internal drop and recreate, the
delete_all_rows method could be invoked with a shared metadata
lock, causing problems if the engine needed exclusive access
to some internal metadata. This problem originated with the
fact that there is no truncate specific handler method, which
ended up leading to a abuse of the delete_all_rows method that
is primarily used for delete operations without a condition.
Solution:
The solution is to introduce a truncate handler method that is
invoked when the engine does not support truncation via a table
drop and recreate. This method is invoked under a exclusive
metadata lock, so that there is only a single instance of the
table when the method is invoked.
Also, the method is not invoked and a error is thrown if
the table is a parent in a non-self-referencing foreign key
relationship. This was necessary to avoid inconsistency as
some integrity checks are bypassed. This is inline with the
fact that truncate is primarily a DDL operation that was
designed to quickly remove all data from a table.
mysql-test/suite/innodb/t/innodb-truncate.test:
Add test cases for truncate and foreign key checks.
Also test that InnoDB resets auto-increment on truncate.
mysql-test/suite/innodb/t/innodb.test:
FK is not necessary, test is related to auto-increment.
Update error number, truncate is no longer invoked if
table is parent in a FK relationship.
mysql-test/suite/innodb/t/innodb_mysql.test:
Update error number, truncate is no longer invoked if
table is parent in a FK relationship.
Use delete instead of truncate, test is used to check
the interaction of FKs, triggers and delete.
mysql-test/suite/parts/inc/partition_check.inc:
Fix typo.
mysql-test/suite/sys_vars/t/foreign_key_checks_func.test:
Update error number, truncate is no longer invoked if
table is parent in a FK relationship.
mysql-test/t/mdl_sync.test:
Modify test case to reflect and ensure that truncate takes
a exclusive metadata lock.
mysql-test/t/trigger-trans.test:
Update error number, truncate is no longer invoked if
table is parent in a FK relationship.
sql/ha_partition.cc:
Reorganize the various truncate methods. delete_all_rows is now
passed directly to the underlying engines, so as truncate. The
code responsible for truncating individual partitions is moved
to ha_partition::truncate_partition, which is invoked when a
ALTER TABLE t1 TRUNCATE PARTITION p statement is executed.
Since the partition truncate no longer can be invoked via
delete, the bitmap operations are not necessary anymore. The
explicit reset of the auto-increment value is also removed
as the underlying engines are now responsible for reseting
the value.
sql/handler.cc:
Wire up the handler truncate method.
sql/handler.h:
Introduce and document the truncate handler method. It assumes
certain use cases of delete_all_rows.
Add method to retrieve the list of foreign keys referencing a
table. Method is used to avoid truncating tables that are
parent in a foreign key relationship.
sql/share/errmsg-utf8.txt:
Add error message for truncate and FK.
sql/sql_lex.h:
Introduce a flag so that the partition engine can detect when
a partition is being truncated. Used to give a special error.
sql/sql_parse.cc:
Function mysql_truncate_table no longer exists.
sql/sql_partition_admin.cc:
Implement the TRUNCATE PARTITION statement.
sql/sql_truncate.cc:
Change the truncate table implementation to use the new truncate
handler method and to not rely on row-by-row delete anymore.
The truncate handler method is always invoked with a exclusive
metadata lock. Also, it is no longer possible to truncate a
table that is parent in some non-self-referencing foreign key.
storage/archive/ha_archive.cc:
Rename method as the description indicates that in the future
this could be a truncate operation.
storage/blackhole/ha_blackhole.cc:
Implement truncate as no operation for the blackhole engine in
order to remain compatible with older releases.
storage/federated/ha_federated.cc:
Introduce truncate method that invokes delete_all_rows.
This is required to support partition truncate as this
form of truncate does not implement the drop and recreate
protocol.
storage/heap/ha_heap.cc:
Introduce truncate method that invokes delete_all_rows.
This is required to support partition truncate as this
form of truncate does not implement the drop and recreate
protocol.
storage/ibmdb2i/ha_ibmdb2i.cc:
Introduce truncate method that invokes delete_all_rows.
This is required to support partition truncate as this
form of truncate does not implement the drop and recreate
protocol.
storage/innobase/handler/ha_innodb.cc:
Rename delete_all_rows to truncate. InnoDB now does truncate
under a exclusive metadata lock.
Introduce and reorganize methods used to retrieve the list
of foreign keys referenced by a or referencing a table.
storage/myisammrg/ha_myisammrg.cc:
Introduce truncate method that invokes delete_all_rows.
This is required in order to remain compatible with earlier
releases where truncate would resort to a row-by-row delete.
2010-10-06 11:34:28 -03:00
|
|
|
DELETE FROM t1;
|
|
|
|
SELECT @a, @b;
|
|
|
|
@a @b
|
|
|
|
1 1
|
2008-03-12 16:13:33 +03:00
|
|
|
INSERT INTO t1 VALUES (1);
|
|
|
|
DELETE FROM t1;
|
|
|
|
SELECT @a, @b;
|
|
|
|
@a @b
|
|
|
|
1 1
|
|
|
|
DROP TABLE t2, t1;
|
A fix and a test case for Bug#26141 mixing table types in trigger
causes full table lock on innodb table.
Also fixes Bug#28502 Triggers that update another innodb table
will block on X lock unnecessarily (duplciate).
Code review fixes.
Both bugs' synopses are misleading: InnoDB table is
not X locked. The statements, however, cannot proceed concurrently,
but this happens due to lock conflicts for tables used in triggers,
not for the InnoDB table.
If a user had an InnoDB table, and two triggers, AFTER UPDATE and
AFTER INSERT, competing for different resources (e.g. two distinct
MyISAM tables), then these two triggers would not be able to execute
concurrently. Moreover, INSERTS/UPDATES of the InnoDB table would
not be able to run concurrently.
The problem had other side-effects (see respective bug reports).
This behavior was a consequence of a shortcoming of the pre-locking
algorithm, which would not distinguish between different DML operations
(e.g. INSERT and DELETE) and pre-lock all the tables
that are used by any trigger defined on the subject table.
The idea of the fix is to extend the pre-locking algorithm to keep track,
for each table, what DML operation it is used for and not
load triggers that are known to never be fired.
mysql-test/r/trigger-trans.result:
Update results (Bug#26141)
mysql-test/r/trigger.result:
Update results (Bug#28502)
mysql-test/t/trigger-trans.test:
Add a test case for Bug#26141 mixing table types in trigger causes
full table lock on innodb table.
mysql-test/t/trigger.test:
Add a test case for Bug#28502 Triggers that update another innodb
table will block echo on X lock unnecessarily. Add more test
coverage for triggers.
sql/item.h:
enum trg_event_type is needed in table.h
sql/sp.cc:
Take into account table_list->trg_event_map when determining
what tables to pre-lock.
After this change, if we attempt to fire a
trigger for which we had not pre-locked any tables, error
'Table was not locked with LOCK TABLES' will be printed.
This, however, should never happen, provided the pre-locking
algorithm has no programming bugs.
Previously a trigger key in the sroutines hash was based on the name
of the table the trigger belongs to. This was possible because we would
always add to the pre-locking list all the triggers defined for a table when
handling this table.
Now the key is based on the name of the trigger, owing
to the fact that a trigger name must be unique in the database it
belongs to.
sql/sp_head.cc:
Generate sroutines hash key in init_spname(). This is a convenient
place since there we have all the necessary information and can
avoid an extra alloc.
Maintain and merge trg_event_map when adding and merging elements
of the pre-locking list.
sql/sp_head.h:
Add ,m_sroutines_key member, used when inserting the sphead for a
trigger into the cache of routines used by a statement.
Previously the key was based on the table name the trigger belonged
to, since for a given table we would add to the sroutines list
all the triggers defined on it.
sql/sql_lex.cc:
Introduce a new lex step: set_trg_event_type_for_tables().
It is called when we have finished parsing but before opening
and locking tables. Now this step is used to evaluate for each
TABLE_LIST instance which INSERT/UPDATE/DELETE operation, if any,
it is used in.
In future this method could be extended to aggregate other information
that is hard to aggregate during parsing.
sql/sql_lex.h:
Add declaration for set_trg_event_type_for_tables().
sql/sql_parse.cc:
Call set_trg_event_type_for_tables() after MYSQLparse(). Remove tabs.
sql/sql_prepare.cc:
Call set_trg_event_type_for_tables() after MYSQLparse().
sql/sql_trigger.cc:
Call set_trg_event_type_for_tables() after MYSQLparse().
sql/sql_trigger.h:
Remove an obsolete member.
sql/sql_view.cc:
Call set_trg_event_type_for_tables() after MYSQLparse().
sql/sql_yacc.yy:
Move assignment of sp_head::m_type before calling sp_head::init_spname(),
one is now used inside another.
sql/table.cc:
Implement TABLE_LIST::set_trg_event_map() - a method that calculates
wh triggers may be fired on this table when executing a statement.
sql/table.h:
Add missing declarations.
Move declaration of trg_event_type from item.h (it will be needed for
trg_event_map bitmap when we start using Bitmap template instead
of uint8).
2007-07-12 22:26:41 +04:00
|
|
|
End of 5.0 tests
|
Fix for BUG#31612
"Trigger fired multiple times leads to gaps in auto_increment sequence".
The bug was that if a trigger fired multiple times inside a top
statement (for example top-statement is a multi-row INSERT,
and trigger is ON INSERT), and that trigger inserted into an auto_increment
column, then gaps could be observed in the auto_increment sequence,
even if there were no other users of the database (no concurrency).
It was wrong usage of THD::auto_inc_intervals_in_cur_stmt_for_binlog.
Note that the fix changes "class handler", I'll tell the Storage Engine API team.
mysql-test/r/trigger-trans.result:
result; before the bugfix, the sequence was 1,2,4,6,8,10,12...
mysql-test/t/trigger-trans.test:
test for BUG#31612
sql/handler.cc:
See revision comment of handler.h.
As THD::auto_inc_intervals_in_cur_stmt_for_binlog is cumulative
over all trigger invokations by the top statement, the
second invokation of the trigger arrived in handler::update_auto_increment()
with already one interval in
THD::auto_inc_intervals_in_cur_stmt_for_binlog. The method thus
believed it had already reserved one interval for that invokation,
thus reserved a twice larger interval (heuristic when we don't know
how large the interval should be: we grow by powers of two). InnoDB
thus increased its internal per-table auto_increment counter by 2
while only one row was to be inserted. Hence a gap in the sequence.
The fix is to use the new handler::auto_inc_intervals_count.
Note that the trigger's statement knows how many rows it is going
to insert, but provides estimation_rows_to_insert == 0 (see comments
in sql_insert.cc why triggers don't call handler::ha_start_bulk_insert()).
* removing white space at end of line
* we don't need to maintain THD::auto_inc_intervals_in_cur_stmt_for_binlog
if no binlogging or if row-based binlogging. Using auto_inc_intervals_count in
the heuristic makes the heuristic independent of binary logging, which is good.
sql/handler.h:
THD::auto_inc_intervals_in_cur_stmt_for_binlog served
- for binlogging
- as a heuristic when we have no estimation of how many records the
statement will insert.
But the first goal needs to be cumulative over all statements which
form a binlog event, while the second one needs to be attached to each
statement. THD::auto_inc_intervals_in_cur_stmt_for_binlog is cumulative,
leading to BUG#31612. So we introduce handler::auto_inc_intervals_count
for the second goal. See the revision comment of handler.cc.
A smaller issue was that, even when the binlog event was only one
statement (no triggers, no stored functions),
THD::auto_inc_intervals_in_cur_stmt.nb_elements() could be lower than
the number of reserved intervals (fooling the heuristic), because its
append() method collapses two contiguous intervals in one.
Note that as auto_inc_intervals_count is in class 'handler' and not
in class 'THD', it does not need to be handled in
THD::reset|restore_sub_statement_state().
sql/log.cc:
Comment is wrong: if auto_increment is second, in handler::update_auto_increment()
'append' is false and so auto_inc_intervals_in_cur_stmt_for_binlog
is empty, we do not come here.
sql/sql_class.h:
comment
2008-10-06 16:06:59 +02:00
|
|
|
BUG#31612
|
|
|
|
Trigger fired multiple times leads to gaps in auto_increment sequence
|
|
|
|
create table t1 (a int, val char(1)) engine=InnoDB;
|
|
|
|
create table t2 (b int auto_increment primary key,
|
|
|
|
val char(1)) engine=InnoDB;
|
|
|
|
create trigger t1_after_insert after
|
|
|
|
insert on t1 for each row insert into t2 set val=NEW.val;
|
|
|
|
insert into t1 values ( 123, 'a'), ( 123, 'b'), ( 123, 'c'),
|
|
|
|
(123, 'd'), (123, 'e'), (123, 'f'), (123, 'g');
|
|
|
|
insert into t1 values ( 654, 'a'), ( 654, 'b'), ( 654, 'c'),
|
|
|
|
(654, 'd'), (654, 'e'), (654, 'f'), (654, 'g');
|
|
|
|
select * from t2 order by b;
|
|
|
|
b val
|
|
|
|
1 a
|
|
|
|
2 b
|
|
|
|
3 c
|
|
|
|
4 d
|
|
|
|
5 e
|
|
|
|
6 f
|
|
|
|
7 g
|
|
|
|
8 a
|
|
|
|
9 b
|
|
|
|
10 c
|
|
|
|
11 d
|
|
|
|
12 e
|
|
|
|
13 f
|
|
|
|
14 g
|
2008-10-07 19:54:12 +03:00
|
|
|
drop trigger t1_after_insert;
|
|
|
|
drop table t1,t2;
|