Details
-
Bug
-
Status: Confirmed (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.6, 10.11, 11.1(EOL), 11.2, 10.7(EOL), 10.8(EOL), 10.9(EOL), 10.10(EOL), 11.0(EOL), 11.3(EOL)
Description
In MDEV-31835 we found out an unintended side effect of MDEV-24818, which affects the following test:
--source include/have_innodb.inc
|
SET foreign_key_checks=0, unique_checks=0; |
CREATE TABLE t (a INT UNIQUE) ENGINE=InnoDB; |
BEGIN; |
INSERT INTO t VALUES(1),(2); |
INSERT IGNORE INTO t VALUES(2); |
COMMIT; |
SELECT * FROM t; |
DROP TABLE t; |
Before MDEV-24818 was implemented in the MariaDB Server 10.6 branch that was eventually released as 10.6.0, only the first INSERT statement was executed in "bulk insert into empty table" mode. After that change, also the INSERT IGNORE statement will be executed in the same mode, covered by the table-level undo log record "on rollback, make the table empty" that was written by the first INSERT statement. That is, the attempt to insert duplicate key a=2 will result in an empty table, instead of a table that contains the two rows (1),(2).
serg wrote in MDEV-31835 that the INSERT and LOAD statements containing an IGNORE clause must be rejected with an error in this case. As far as I understand, this would have to be implemented in the functions mysql_insert() and mysql_load().
If we want to limit this to the case of InnoDB bulk insert and not the generic case of unique_checks=0, some storage engine API change may be necessary, to query the value of InnoDB trx_t::bulk_insert.
Attachments
Issue Links
- relates to
-
MDEV-24818 Concurrent use of InnoDB table is impossible until the first transaction is finished
- Closed
-
MDEV-25036 use bulk insert optimization for multiple insert statements
- Open
-
MDEV-31835 LOAD DATA into InnoDB w/partitions: huge performance loss, affected 10.6+
- Closed
-
MDEV-32439 INSERT IGNORE on constraints result in ERROR rather than warning
- Closed