[MDEV-22604] INSERT DELAYED treated as usual INSERT if table has check constraints Created: 2020-05-17  Updated: 2020-05-19  Resolved: 2020-05-19

Status: Closed
Project: MariaDB Server
Component/s: Data Manipulation - Insert, Documentation
Affects Version/s: 10.2, 10.3, 10.4, 10.5
Fix Version/s: N/A

Type: Bug Priority: Minor
Reporter: Elena Stepanova Assignee: Ian Gilfillan
Resolution: Fixed Votes: 0
Labels: None


 Description   

create table t1 (a int primary key, check(a<10)) engine=MyISAM;
insert delayed into t1 values (1),(1);
 
# cleanup
drop table t1;

INSERT DELAYED above results in the error:

10.2 3f12a596

At line 2: query 'insert delayed into t1 values (1),(1)' failed: 1062: Duplicate entry '1' for key 'PRIMARY'

It shouldn't be happening if it is treated as INSERT DELAYED. If we remove CHECK from the table definition, INSERT DELAYED doesn't return the error.

The fact that DELAYED is ignored can also be observed in a more intuitive situation, if you lock the table in another client connection. Naturally INSERT DELAYED should return immediately, but with CHECK on the table it doesn't.

Reproducible with table-level and column-level check constraints, on 10.2-10.5.

Note:
It may be intentional, and if it was not, it might not be worth fixing. In this case, please re-categorize as Documentation issue, so that it's mentioned as a limitation in the documentation for CHECK constraints and for INSERT DELAYED, and reassign accordingly.



 Comments   
Comment by Elena Stepanova [ 2020-05-17 ]

As a consequence, INSERT DELAYED does not work for tables with implicit check constraints, e.g. for application period tables.

Comment by Sergei Golubchik [ 2020-05-18 ]

This is intentional. There are many preconditions for INSERT DELAYED to work, if they aren't met it's converted to a normal INSERT. CHECK constraints, triggers, skip-new mode, max_insert_delayed_threads == 0, stored functions, replication, etc.

Comment by Ian Gilfillan [ 2020-05-19 ]

Added to the list of limitations on the page

Generated at Thu Feb 08 09:16:02 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.